Showing preview only (5,218K chars total). Download the full file or copy to clipboard to get everything.
Repository: modelcontextprotocol/modelcontextprotocol
Branch: main
Commit: fe366986cc4c
Files: 500
Total size: 4.9 MB
Directory structure:
gitextract_0qxsxgk9/
├── .claude-plugin/
│ └── marketplace.json
├── .gitattributes
├── .github/
│ ├── CODEOWNERS
│ ├── ISSUE_TEMPLATE/
│ │ ├── bug_report.yml
│ │ ├── config.yml
│ │ └── work_tracking.yml
│ ├── dependabot.yml
│ ├── labeler.yml
│ └── workflows/
│ ├── blog-preview.yml
│ ├── deploy-blog.yml
│ ├── labeler.yml
│ ├── main.yml
│ ├── markdown-format.yml
│ ├── render-seps.yml
│ ├── sep-lifecycle-manual.yml
│ ├── sep-lifecycle.yml
│ ├── sep-reminder.yml
│ ├── slash-commands.yml
│ └── stage-blog.yml
├── .gitignore
├── .npmrc
├── .nvmrc
├── .prettierignore
├── .prettierrc.json
├── .prototools
├── AGENTS.md
├── ANTITRUST.md
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── GOVERNANCE.md
├── LICENSE
├── MAINTAINERS.md
├── README.md
├── SECURITY.md
├── blog/
│ ├── .gitignore
│ ├── archetypes/
│ │ └── default.md
│ ├── assets/
│ │ └── css/
│ │ └── extended/
│ │ └── custom.css
│ ├── content/
│ │ ├── _index.md
│ │ ├── archives.md
│ │ ├── posts/
│ │ │ ├── 2025-07-29-prompts-for-automation.md
│ │ │ ├── 2025-07-31-governance-for-mcp.md
│ │ │ ├── 2025-09-05-php-sdk.md
│ │ │ ├── 2025-09-08-mcp-registry-preview.md
│ │ │ ├── 2025-09-26-mcp-next-version-update.md
│ │ │ ├── 2025-11-03-using-server-instructions.md
│ │ │ ├── 2025-11-20-adopting-mcpb.md
│ │ │ ├── 2025-11-21-mcp-apps.md
│ │ │ ├── 2025-11-25-first-mcp-anniversary.md
│ │ │ ├── 2025-11-28-sep-process-update.md
│ │ │ ├── 2025-12-09-mcp-joins-agentic-ai-foundation.md
│ │ │ ├── 2025-12-19-mcp-transport-future.md
│ │ │ ├── 2026-01-22-core-maintainer-update.md
│ │ │ ├── 2026-01-26-mcp-apps.md
│ │ │ ├── 2026-03-09-roadmap-update.md
│ │ │ ├── 2026-03-11-understanding-mcp-extensions.md
│ │ │ ├── 2026-03-16-tool-annotations.md
│ │ │ ├── client_registration/
│ │ │ │ └── index.md
│ │ │ └── welcome-to-mcp-blog.md
│ │ └── search.md
│ ├── go.mod
│ ├── go.sum
│ ├── hugo.toml
│ ├── layouts/
│ │ ├── _default/
│ │ │ ├── archives.html
│ │ │ ├── list.html
│ │ │ ├── search.html
│ │ │ └── terms.html
│ │ ├── _markup/
│ │ │ └── render-codeblock-mermaid.html
│ │ ├── baseof.html
│ │ ├── index.html
│ │ ├── partials/
│ │ │ ├── extend_head.html
│ │ │ ├── footer.html
│ │ │ ├── google_analytics.html
│ │ │ ├── header.html
│ │ │ ├── post_meta.html
│ │ │ ├── post_nav_links.html
│ │ │ └── templates/
│ │ │ └── schema_json.html
│ │ └── shortcodes/
│ │ ├── button.html
│ │ └── youtube.html
│ └── static/
│ └── CNAME
├── docs/
│ ├── .well-known/
│ │ └── security.txt
│ ├── clients.mdx
│ ├── community/
│ │ ├── antitrust.mdx
│ │ ├── communication.mdx
│ │ ├── contributing.mdx
│ │ ├── contributor-ladder.mdx
│ │ ├── design-principles.mdx
│ │ ├── governance.mdx
│ │ ├── sdk-tiers.mdx
│ │ ├── sep-guidelines.mdx
│ │ └── working-interest-groups.mdx
│ ├── development/
│ │ └── roadmap.mdx
│ ├── docs/
│ │ ├── develop/
│ │ │ ├── build-client.mdx
│ │ │ ├── build-server.mdx
│ │ │ ├── connect-local-servers.mdx
│ │ │ └── connect-remote-servers.mdx
│ │ ├── getting-started/
│ │ │ └── intro.mdx
│ │ ├── learn/
│ │ │ ├── architecture.mdx
│ │ │ ├── client-concepts.mdx
│ │ │ └── server-concepts.mdx
│ │ ├── sdk.mdx
│ │ ├── tools/
│ │ │ └── inspector.mdx
│ │ └── tutorials/
│ │ ├── security/
│ │ │ ├── authorization.mdx
│ │ │ └── security_best_practices.mdx
│ │ └── use-local-mcp-server.mdx
│ ├── docs.json
│ ├── examples.mdx
│ ├── extensions/
│ │ ├── apps/
│ │ │ ├── build.mdx
│ │ │ └── overview.mdx
│ │ ├── auth/
│ │ │ ├── enterprise-managed-authorization.mdx
│ │ │ ├── oauth-client-credentials.mdx
│ │ │ └── overview.mdx
│ │ ├── client-matrix.mdx
│ │ └── overview.mdx
│ ├── faqs.mdx
│ ├── footer.js
│ ├── images/
│ │ └── java/
│ │ └── class-diagrams.puml
│ ├── legacy/
│ │ ├── concepts/
│ │ │ ├── architecture.mdx
│ │ │ ├── elicitation.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── roots.mdx
│ │ │ ├── sampling.mdx
│ │ │ ├── tools.mdx
│ │ │ └── transports.mdx
│ │ └── tools/
│ │ └── debugging.mdx
│ ├── registry/
│ │ ├── about.mdx
│ │ ├── authentication.mdx
│ │ ├── faq.mdx
│ │ ├── github-actions.mdx
│ │ ├── moderation-policy.mdx
│ │ ├── package-types.mdx
│ │ ├── quickstart.mdx
│ │ ├── registry-aggregators.mdx
│ │ ├── remote-servers.mdx
│ │ ├── terms-of-service.mdx
│ │ └── versioning.mdx
│ ├── sdk/
│ │ └── java/
│ │ ├── mcp-client.mdx
│ │ ├── mcp-overview.mdx
│ │ └── mcp-server.mdx
│ ├── seps/
│ │ ├── 1024-mcp-client-security-requirements-for-local-server-.mdx
│ │ ├── 1034--support-default-values-for-all-primitive-types-in.mdx
│ │ ├── 1036-url-mode-elicitation-for-secure-out-of-band-intera.mdx
│ │ ├── 1046-support-oauth-client-credentials-flow-in-authoriza.mdx
│ │ ├── 1302-formalize-working-groups-and-interest-groups-in-mc.mdx
│ │ ├── 1303-input-validation-errors-as-tool-execution-errors.mdx
│ │ ├── 1319-decouple-request-payload-from-rpc-methods-definiti.mdx
│ │ ├── 1330-elicitation-enum-schema-improvements-and-standards.mdx
│ │ ├── 1577--sampling-with-tools.mdx
│ │ ├── 1613-establish-json-schema-2020-12-as-default-dialect-f.mdx
│ │ ├── 1686-tasks.mdx
│ │ ├── 1699-support-sse-polling-via-server-side-disconnect.mdx
│ │ ├── 1730-sdks-tiering-system.mdx
│ │ ├── 1850-pr-based-sep-workflow.mdx
│ │ ├── 1865-mcp-apps-interactive-user-interfaces-for-mcp.mdx
│ │ ├── 2085-governance-succession-and-amendment.mdx
│ │ ├── 2133-extensions.mdx
│ │ ├── 2148-contributor-ladder.mdx
│ │ ├── 2149-working-group-charter-template.mdx
│ │ ├── 2260-Require-Server-requests-to-be-associated-with-Client-requests.mdx
│ │ ├── 414-request-meta.mdx
│ │ ├── 932-model-context-protocol-governance.mdx
│ │ ├── 973-expose-additional-metadata-for-implementations-res.mdx
│ │ ├── 985-align-oauth-20-protected-resource-metadata-with-rf.mdx
│ │ ├── 986-specify-format-for-tool-names.mdx
│ │ ├── 990-enable-enterprise-idp-policy-controls-during-mcp-o.mdx
│ │ ├── 991-enable-url-based-client-registration-using-oauth-c.mdx
│ │ ├── 994-shared-communication-practicesguidelines.mdx
│ │ └── index.mdx
│ ├── snippets/
│ │ └── snippet-intro.mdx
│ ├── spec-version-warning.js
│ ├── specification/
│ │ ├── 2024-11-05/
│ │ │ ├── architecture/
│ │ │ │ └── index.mdx
│ │ │ ├── basic/
│ │ │ │ ├── index.mdx
│ │ │ │ ├── lifecycle.mdx
│ │ │ │ ├── messages.mdx
│ │ │ │ ├── transports.mdx
│ │ │ │ └── utilities/
│ │ │ │ ├── cancellation.mdx
│ │ │ │ ├── ping.mdx
│ │ │ │ └── progress.mdx
│ │ │ ├── client/
│ │ │ │ ├── roots.mdx
│ │ │ │ └── sampling.mdx
│ │ │ ├── index.mdx
│ │ │ └── server/
│ │ │ ├── index.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── tools.mdx
│ │ │ └── utilities/
│ │ │ ├── completion.mdx
│ │ │ ├── logging.mdx
│ │ │ └── pagination.mdx
│ │ ├── 2025-03-26/
│ │ │ ├── architecture/
│ │ │ │ └── index.mdx
│ │ │ ├── basic/
│ │ │ │ ├── authorization.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ ├── lifecycle.mdx
│ │ │ │ ├── transports.mdx
│ │ │ │ └── utilities/
│ │ │ │ ├── cancellation.mdx
│ │ │ │ ├── ping.mdx
│ │ │ │ └── progress.mdx
│ │ │ ├── changelog.mdx
│ │ │ ├── client/
│ │ │ │ ├── roots.mdx
│ │ │ │ └── sampling.mdx
│ │ │ ├── index.mdx
│ │ │ └── server/
│ │ │ ├── index.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── tools.mdx
│ │ │ └── utilities/
│ │ │ ├── completion.mdx
│ │ │ ├── logging.mdx
│ │ │ └── pagination.mdx
│ │ ├── 2025-06-18/
│ │ │ ├── architecture/
│ │ │ │ └── index.mdx
│ │ │ ├── basic/
│ │ │ │ ├── authorization.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ ├── lifecycle.mdx
│ │ │ │ ├── security_best_practices.mdx
│ │ │ │ ├── transports.mdx
│ │ │ │ └── utilities/
│ │ │ │ ├── cancellation.mdx
│ │ │ │ ├── ping.mdx
│ │ │ │ └── progress.mdx
│ │ │ ├── changelog.mdx
│ │ │ ├── client/
│ │ │ │ ├── elicitation.mdx
│ │ │ │ ├── roots.mdx
│ │ │ │ └── sampling.mdx
│ │ │ ├── index.mdx
│ │ │ ├── schema.mdx
│ │ │ └── server/
│ │ │ ├── index.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── tools.mdx
│ │ │ └── utilities/
│ │ │ ├── completion.mdx
│ │ │ ├── logging.mdx
│ │ │ └── pagination.mdx
│ │ ├── 2025-11-25/
│ │ │ ├── architecture/
│ │ │ │ └── index.mdx
│ │ │ ├── basic/
│ │ │ │ ├── authorization.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ ├── lifecycle.mdx
│ │ │ │ ├── security_best_practices.mdx
│ │ │ │ ├── transports.mdx
│ │ │ │ └── utilities/
│ │ │ │ ├── cancellation.mdx
│ │ │ │ ├── ping.mdx
│ │ │ │ ├── progress.mdx
│ │ │ │ └── tasks.mdx
│ │ │ ├── changelog.mdx
│ │ │ ├── client/
│ │ │ │ ├── elicitation.mdx
│ │ │ │ ├── roots.mdx
│ │ │ │ └── sampling.mdx
│ │ │ ├── index.mdx
│ │ │ ├── schema.mdx
│ │ │ └── server/
│ │ │ ├── index.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── tools.mdx
│ │ │ └── utilities/
│ │ │ ├── completion.mdx
│ │ │ ├── logging.mdx
│ │ │ └── pagination.mdx
│ │ ├── draft/
│ │ │ ├── architecture/
│ │ │ │ └── index.mdx
│ │ │ ├── basic/
│ │ │ │ ├── authorization.mdx
│ │ │ │ ├── index.mdx
│ │ │ │ ├── lifecycle.mdx
│ │ │ │ ├── transports.mdx
│ │ │ │ └── utilities/
│ │ │ │ ├── cancellation.mdx
│ │ │ │ ├── ping.mdx
│ │ │ │ ├── progress.mdx
│ │ │ │ └── tasks.mdx
│ │ │ ├── changelog.mdx
│ │ │ ├── client/
│ │ │ │ ├── elicitation.mdx
│ │ │ │ ├── roots.mdx
│ │ │ │ └── sampling.mdx
│ │ │ ├── index.mdx
│ │ │ ├── schema.mdx
│ │ │ └── server/
│ │ │ ├── index.mdx
│ │ │ ├── prompts.mdx
│ │ │ ├── resources.mdx
│ │ │ ├── tools.mdx
│ │ │ └── utilities/
│ │ │ ├── completion.mdx
│ │ │ ├── logging.mdx
│ │ │ └── pagination.mdx
│ │ └── versioning.mdx
│ ├── style.css
│ └── tutorials/
│ ├── building-a-client-node.mdx
│ └── building-mcp-with-llms.mdx
├── eslint.config.mjs
├── migrate_seps.js
├── package.json
├── plugins/
│ └── mcp-spec/
│ ├── .claude-plugin/
│ │ └── plugin.json
│ ├── README.md
│ └── skills/
│ └── search-mcp-github/
│ └── SKILL.md
├── schema/
│ ├── 2024-11-05/
│ │ ├── schema.json
│ │ └── schema.ts
│ ├── 2025-03-26/
│ │ ├── schema.json
│ │ └── schema.ts
│ ├── 2025-06-18/
│ │ ├── schema.json
│ │ ├── schema.mdx
│ │ └── schema.ts
│ ├── 2025-11-25/
│ │ ├── schema.json
│ │ ├── schema.mdx
│ │ └── schema.ts
│ └── draft/
│ ├── examples/
│ │ ├── AudioContent/
│ │ │ └── audio-wav-content.json
│ │ ├── BlobResourceContents/
│ │ │ └── image-file-contents.json
│ │ ├── BooleanSchema/
│ │ │ └── boolean-input-schema.json
│ │ ├── CallToolRequest/
│ │ │ └── call-tool-request.json
│ │ ├── CallToolRequestParams/
│ │ │ ├── get-weather-tool-call-params.json
│ │ │ └── tool-call-params-with-progress-token.json
│ │ ├── CallToolResult/
│ │ │ ├── invalid-tool-input-error.json
│ │ │ ├── result-with-structured-content.json
│ │ │ └── result-with-unstructured-text.json
│ │ ├── CallToolResultResponse/
│ │ │ └── call-tool-result-response.json
│ │ ├── CancelledNotification/
│ │ │ └── user-requested-cancellation.json
│ │ ├── CancelledNotificationParams/
│ │ │ └── user-requested-cancellation.json
│ │ ├── ClientCapabilities/
│ │ │ ├── elicitation-form-and-url-mode-support.json
│ │ │ ├── elicitation-form-only-implicit.json
│ │ │ ├── extensions-ui-mime-types.json
│ │ │ ├── roots-list-changed-notifications.json
│ │ │ ├── roots-minimum-baseline-support.json
│ │ │ ├── sampling-context-inclusion-support-soft-deprecated.json
│ │ │ ├── sampling-minimum-baseline-support.json
│ │ │ └── sampling-tool-use-support.json
│ │ ├── CompleteRequest/
│ │ │ └── completion-request.json
│ │ ├── CompleteRequestParams/
│ │ │ ├── prompt-argument-completion-with-context.json
│ │ │ └── prompt-argument-completion.json
│ │ ├── CompleteResult/
│ │ │ ├── multiple-completion-values-with-more-available.json
│ │ │ └── single-completion-value.json
│ │ ├── CompleteResultResponse/
│ │ │ └── completion-result-response.json
│ │ ├── CreateMessageRequest/
│ │ │ └── sampling-request.json
│ │ ├── CreateMessageRequestParams/
│ │ │ ├── basic-request.json
│ │ │ ├── follow-up-with-tool-results.json
│ │ │ └── request-with-tools.json
│ │ ├── CreateMessageResult/
│ │ │ ├── final-response.json
│ │ │ ├── text-response.json
│ │ │ └── tool-use-response.json
│ │ ├── CreateMessageResultResponse/
│ │ │ └── sampling-result-response.json
│ │ ├── ElicitRequest/
│ │ │ └── elicitation-request.json
│ │ ├── ElicitRequestFormParams/
│ │ │ ├── elicit-multiple-fields.json
│ │ │ └── elicit-single-field.json
│ │ ├── ElicitRequestURLParams/
│ │ │ └── elicit-sensitive-data.json
│ │ ├── ElicitResult/
│ │ │ ├── accept-url-mode-no-content.json
│ │ │ ├── input-multiple-fields.json
│ │ │ └── input-single-field.json
│ │ ├── ElicitResultResponse/
│ │ │ └── elicitation-result-response.json
│ │ ├── ElicitationCompleteNotification/
│ │ │ └── elicitation-complete.json
│ │ ├── EmbeddedResource/
│ │ │ └── embedded-file-resource-with-annotations.json
│ │ ├── GetPromptRequest/
│ │ │ └── get-prompt-request.json
│ │ ├── GetPromptRequestParams/
│ │ │ └── get-code-review-prompt.json
│ │ ├── GetPromptResult/
│ │ │ └── code-review-prompt.json
│ │ ├── GetPromptResultResponse/
│ │ │ └── get-prompt-result-response.json
│ │ ├── ImageContent/
│ │ │ └── image-png-content-with-annotations.json
│ │ ├── InitializeRequest/
│ │ │ └── initialize-request.json
│ │ ├── InitializeRequestParams/
│ │ │ └── full-client-capabilities.json
│ │ ├── InitializeResult/
│ │ │ ├── full-server-capabilities.json
│ │ │ └── with-instructions.json
│ │ ├── InitializeResultResponse/
│ │ │ └── initialize-result-response.json
│ │ ├── InitializedNotification/
│ │ │ └── initialized-notification.json
│ │ ├── InternalError/
│ │ │ └── unexpected-error.json
│ │ ├── InvalidParamsError/
│ │ │ ├── invalid-cursor.json
│ │ │ ├── invalid-tool-arguments.json
│ │ │ ├── unknown-prompt.json
│ │ │ └── unknown-tool.json
│ │ ├── ListPromptsRequest/
│ │ │ └── list-prompts-request.json
│ │ ├── ListPromptsResult/
│ │ │ └── prompts-list-with-cursor.json
│ │ ├── ListPromptsResultResponse/
│ │ │ └── list-prompts-result-response.json
│ │ ├── ListResourceTemplatesRequest/
│ │ │ └── list-resource-templates-request.json
│ │ ├── ListResourceTemplatesResult/
│ │ │ └── resource-templates-list.json
│ │ ├── ListResourceTemplatesResultResponse/
│ │ │ └── list-resource-templates-result-response.json
│ │ ├── ListResourcesRequest/
│ │ │ └── list-resources-request.json
│ │ ├── ListResourcesResult/
│ │ │ └── resources-list-with-cursor.json
│ │ ├── ListResourcesResultResponse/
│ │ │ └── list-resources-result-response.json
│ │ ├── ListRootsRequest/
│ │ │ └── list-roots-request.json
│ │ ├── ListRootsResult/
│ │ │ ├── multiple-root-directories.json
│ │ │ └── single-root-directory.json
│ │ ├── ListRootsResultResponse/
│ │ │ └── list-roots-result-response.json
│ │ ├── ListToolsRequest/
│ │ │ └── list-tools-request.json
│ │ ├── ListToolsResult/
│ │ │ └── tools-list-with-cursor.json
│ │ ├── ListToolsResultResponse/
│ │ │ └── list-tools-result-response.json
│ │ ├── LoggingMessageNotification/
│ │ │ └── log-database-connection-failed.json
│ │ ├── LoggingMessageNotificationParams/
│ │ │ └── log-database-connection-failed.json
│ │ ├── MethodNotFoundError/
│ │ │ └── roots-not-supported.json
│ │ ├── ModelPreferences/
│ │ │ └── with-hints-and-priorities.json
│ │ ├── NumberSchema/
│ │ │ └── number-input-schema.json
│ │ ├── PaginatedRequestParams/
│ │ │ └── list-with-cursor.json
│ │ ├── ParseError/
│ │ │ └── invalid-json.json
│ │ ├── PingRequest/
│ │ │ └── ping-request.json
│ │ ├── PingResultResponse/
│ │ │ └── ping-result-response.json
│ │ ├── ProgressNotification/
│ │ │ └── progress-message.json
│ │ ├── ProgressNotificationParams/
│ │ │ └── progress-message.json
│ │ ├── PromptListChangedNotification/
│ │ │ └── prompts-list-changed.json
│ │ ├── ReadResourceRequest/
│ │ │ └── read-resource-request.json
│ │ ├── ReadResourceResult/
│ │ │ └── file-resource-contents.json
│ │ ├── ReadResourceResultResponse/
│ │ │ └── read-resource-result-response.json
│ │ ├── Resource/
│ │ │ └── file-resource-with-annotations.json
│ │ ├── ResourceLink/
│ │ │ └── file-resource-link.json
│ │ ├── ResourceListChangedNotification/
│ │ │ └── resources-list-changed.json
│ │ ├── ResourceUpdatedNotification/
│ │ │ └── file-resource-updated-notification.json
│ │ ├── ResourceUpdatedNotificationParams/
│ │ │ └── file-resource-updated.json
│ │ ├── Root/
│ │ │ └── project-directory.json
│ │ ├── RootsListChangedNotification/
│ │ │ └── roots-list-changed.json
│ │ ├── SamplingMessage/
│ │ │ ├── multiple-content-blocks.json
│ │ │ └── single-content-block.json
│ │ ├── ServerCapabilities/
│ │ │ ├── completions-minimum-baseline-support.json
│ │ │ ├── extensions-ui.json
│ │ │ ├── logging-minimum-baseline-support.json
│ │ │ ├── prompts-list-changed-notifications.json
│ │ │ ├── prompts-minimum-baseline-support.json
│ │ │ ├── resources-all-notifications.json
│ │ │ ├── resources-list-changed-notifications-only.json
│ │ │ ├── resources-minimum-baseline-support.json
│ │ │ ├── resources-subscription-to-individual-resource-updates-only.json
│ │ │ ├── tools-list-changed-notifications.json
│ │ │ └── tools-minimum-baseline-support.json
│ │ ├── SetLevelRequest/
│ │ │ └── set-logging-level-request.json
│ │ ├── SetLevelRequestParams/
│ │ │ └── set-log-level-to-info.json
│ │ ├── SetLevelResultResponse/
│ │ │ └── set-logging-level-result-response.json
│ │ ├── StringSchema/
│ │ │ └── email-input-schema.json
│ │ ├── SubscribeRequest/
│ │ │ └── subscribe-request.json
│ │ ├── SubscribeRequestParams/
│ │ │ └── subscribe-to-file-resource.json
│ │ ├── SubscribeResultResponse/
│ │ │ └── subscribe-result-response.json
│ │ ├── TextContent/
│ │ │ └── text-content.json
│ │ ├── TextResourceContents/
│ │ │ └── text-file-contents.json
│ │ ├── TitledMultiSelectEnumSchema/
│ │ │ └── titled-color-multi-select-schema.json
│ │ ├── TitledSingleSelectEnumSchema/
│ │ │ └── titled-color-select-schema.json
│ │ ├── Tool/
│ │ │ ├── with-default-2020-12-input-schema.json
│ │ │ ├── with-explicit-draft-07-input-schema.json
│ │ │ ├── with-no-parameters.json
│ │ │ └── with-output-schema-for-structured-content.json
│ │ ├── ToolListChangedNotification/
│ │ │ └── tools-list-changed.json
│ │ ├── ToolResultContent/
│ │ │ └── get-weather-tool-result.json
│ │ ├── ToolUseContent/
│ │ │ └── get-weather-tool-use.json
│ │ ├── URLElicitationRequiredError/
│ │ │ └── authorization-required.json
│ │ ├── UnsubscribeRequest/
│ │ │ └── unsubscribe-request.json
│ │ ├── UnsubscribeResultResponse/
│ │ │ └── unsubscribe-result-response.json
│ │ ├── UntitledMultiSelectEnumSchema/
│ │ │ └── color-multi-select-schema.json
│ │ └── UntitledSingleSelectEnumSchema/
│ │ └── color-select-schema.json
│ ├── schema.json
│ ├── schema.mdx
│ └── schema.ts
├── scripts/
│ ├── check-mdx-comments.ts
│ ├── generate-schemas.ts
│ ├── pull-registry-docs.sh
│ ├── render-seps.ts
│ └── validate-examples.ts
├── seps/
│ ├── .keep
│ ├── 1024-mcp-client-security-requirements-for-local-server-.md
│ ├── 1034--support-default-values-for-all-primitive-types-in.md
│ ├── 1036-url-mode-elicitation-for-secure-out-of-band-intera.md
│ ├── 1046-support-oauth-client-credentials-flow-in-authoriza.md
│ ├── 1302-formalize-working-groups-and-interest-groups-in-mc.md
│ ├── 1303-input-validation-errors-as-tool-execution-errors.md
│ ├── 1319-decouple-request-payload-from-rpc-methods-definiti.md
│ ├── 1330-elicitation-enum-schema-improvements-and-standards.md
│ ├── 1577--sampling-with-tools.md
│ ├── 1613-establish-json-schema-2020-12-as-default-dialect-f.md
│ ├── 1686-tasks.md
│ ├── 1699-support-sse-polling-via-server-side-disconnect.md
│ ├── 1730-sdks-tiering-system.md
│ ├── 1850-pr-based-sep-workflow.md
│ ├── 1865-mcp-apps-interactive-user-interfaces-for-mcp.md
│ ├── 2085-governance-succession-and-amendment.md
│ ├── 2133-extensions.md
│ ├── 2148-contributor-ladder.md
│ ├── 2260-Require-Server-requests-to-be-associated-with-Client-requests.md
│ ├── 414-request-meta.md
│ ├── 932-model-context-protocol-governance.md
│ ├── 973-expose-additional-metadata-for-implementations-res.md
│ ├── 985-align-oauth-20-protected-resource-metadata-with-rf.md
│ ├── 986-specify-format-for-tool-names.md
│ ├── 990-enable-enterprise-idp-policy-controls-during-mcp-o.md
│ ├── 991-enable-url-based-client-registration-using-oauth-c.md
│ ├── 994-shared-communication-practicesguidelines.md
│ ├── README.md
│ └── TEMPLATE.md
├── tools/
│ └── sep-automation/
│ ├── .gitignore
│ ├── package.json
│ ├── src/
│ │ ├── actions/
│ │ │ ├── comment.ts
│ │ │ ├── ping.ts
│ │ │ └── transition.ts
│ │ ├── config.ts
│ │ ├── github/
│ │ │ ├── client.ts
│ │ │ └── types.ts
│ │ ├── hooks/
│ │ │ ├── discord.ts
│ │ │ ├── registry.ts
│ │ │ └── types.ts
│ │ ├── index.ts
│ │ ├── maintainers/
│ │ │ └── resolver.ts
│ │ ├── processor.ts
│ │ ├── rules.ts
│ │ ├── sep/
│ │ │ ├── analyzer.ts
│ │ │ ├── detector.ts
│ │ │ └── types.ts
│ │ ├── types.ts
│ │ └── utils/
│ │ ├── dates.ts
│ │ ├── errors.ts
│ │ └── index.ts
│ ├── test/
│ │ ├── mocks.ts
│ │ └── unit/
│ │ ├── comment.test.ts
│ │ ├── config.test.ts
│ │ ├── hooks.test.ts
│ │ ├── ping.test.ts
│ │ ├── sep-types.test.ts
│ │ └── transition.test.ts
│ ├── tsconfig.json
│ └── vitest.config.ts
├── tsconfig.json
├── typedoc.config.mjs
└── typedoc.plugin.mjs
================================================
FILE CONTENTS
================================================
================================================
FILE: .claude-plugin/marketplace.json
================================================
{
"name": "modelcontextprotocol",
"owner": {
"name": "Model Context Protocol"
},
"metadata": {
"description": "Official Claude Code plugins for the Model Context Protocol"
},
"plugins": [
{
"name": "mcp-spec",
"source": "./plugins/mcp-spec",
"description": "Skills for researching and contributing to the MCP specification"
}
]
}
================================================
FILE: .gitattributes
================================================
package-lock.json linguist-generated=true
schema/*/schema.json linguist-generated=true
docs/specification/*/schema.md linguist-generated=true
docs/specification/*/schema.mdx linguist-generated=true
docs/community/seps/index.mdx linguist-generated=true
docs/community/seps/[0-9]*.mdx linguist-generated=true
================================================
FILE: .github/CODEOWNERS
================================================
# CODEOWNERS file for MCP Specification repository
# General documentation ownership - @modelcontextprotocol/docs-maintainers and core-maintainers own all of /docs
/docs/ @modelcontextprotocol/docs-maintainers @modelcontextprotocol/core-maintainers
# Specific ownership - @core-maintainer team owns docs/specification and schema/ directories
/docs/specification/ @modelcontextprotocol/core-maintainers
/schema/ @modelcontextprotocol/core-maintainers
# Blog ownership
/blog/ @dsp-ant @localden
# Authorization-related files - @auth team should be notified
/docs/specification/**/authorization.mdx @modelcontextprotocol/core-maintainers @modelcontextprotocol/auth-wg
/docs/specification/**/security_best_practices.mdx @modelcontextprotocol/core-maintainers @modelcontextprotocol/auth-wg
/docs/docs/tutorials/security/security_best_practices.mdx @modelcontextprotocol/core-maintainers @modelcontextprotocol/auth-wg
# GitHub configuration (workflows, issue templates, etc.)
/.github/ @modelcontextprotocol/core-maintainers @modelcontextprotocol/docs-maintainers
# Agent documentation
/AGENTS.md @modelcontextprotocol/core-maintainers @modelcontextprotocol/docs-maintainers
================================================
FILE: .github/ISSUE_TEMPLATE/bug_report.yml
================================================
name: Report a bug
description: >
An aspect of the MCP specification doesn't work as expected, or our
documentation is wrong.
labels: [bug, needs-triage]
body:
- type: markdown
attributes:
value: |
Use this form for problems with the **MCP specification itself** or
with the **documentation on modelcontextprotocol.io**.
- If the bug is in a specific SDK (TypeScript, Python, etc.), file
it in [that SDK's repository](https://modelcontextprotocol.io/docs/sdk)
instead.
- If the bug is in how **Claude** (Claude Desktop, claude.ai) uses
MCP, file it at [anthropics/claude-ai-mcp](https://github.com/anthropics/claude-ai-mcp).
- If you want to propose a new feature or a breaking change, that's
a [SEP](https://modelcontextprotocol.io/community/sep-guidelines),
not a bug.
- type: dropdown
id: kind
attributes:
label: What's broken?
options:
- The spec defines behavior that doesn't work in practice
- The spec is ambiguous or self-contradictory
- The spec doesn't cover a case it clearly should
- The JSON schema is wrong (incorrect type, constraint, or field)
- The JSON schema disagrees with the spec prose
- The spec conflicts with an RFC or standard it references
- An example in the spec is wrong or won't run
- The documentation is wrong or misleading
- A docs page is missing or a link is broken
validations:
required: true
- type: input
id: location
attributes:
label: Where in the spec or docs?
description: >
Link to the spec section, schema file, or docs page. Include a
version tag or permalink if the content might change.
placeholder: https://modelcontextprotocol.io/specification/2025-06-18/...
validations:
required: true
- type: textarea
id: expected
attributes:
label: What should happen?
description: What you expected the spec to say, or what behavior you expected.
validations:
required: true
- type: textarea
id: actual
attributes:
label: What actually happens?
description: >
Quote the spec text, describe the broken behavior, or paste the
error. If two implementations disagree, say which ones and how.
validations:
required: true
- type: textarea
id: context
attributes:
label: Anything else?
description: >
Relevant SDK versions, related issues, or workarounds you've found.
validations:
required: false
================================================
FILE: .github/ISSUE_TEMPLATE/config.yml
================================================
blank_issues_enabled: false
contact_links:
- name: Submit a Spec Enhancement Proposal (SEP)
url: https://modelcontextprotocol.io/community/sep-guidelines
about: >
SEPs are the mechanism for proposing new protocol features, breaking
changes, or governance changes. They are submitted as pull requests
adding a file to the seps/ directory — not as issues. Read the SEP
guidelines before opening your PR.
- name: Report an SDK bug
url: https://modelcontextprotocol.io/docs/sdk
about: >
Bugs in a specific SDK (TypeScript, Python, Go, etc.) should be filed
in that SDK's own repository. The SDK documentation lists every
official SDK with a link to its issue tracker.
================================================
FILE: .github/ISSUE_TEMPLATE/work_tracking.yml
================================================
name: Work tracking
description: >
Track work that's already been discussed and agreed on — not a new
proposal.
labels: [tracking]
body:
- type: markdown
attributes:
value: |
This template is for work that's **already been discussed and
agreed on** — in a SEP, a working group, a maintainer sync,
a prior issue, wherever. It gives that work a place to be assigned,
linked from PRs, and closed.
If you're proposing something **new**, this is the wrong template.
Open a [SEP](https://modelcontextprotocol.io/community/sep-guidelines)
for protocol changes, or a bug report for things that are broken.
- type: input
id: source
attributes:
label: Where was this agreed?
description: >
Link to the discussion. If it was a synchronous conversation
without a link, say where and when.
placeholder: https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/...
validations:
required: true
- type: textarea
id: description
attributes:
label: Description
description: >
Whatever's useful. Summary, task list, acceptance criteria, open
questions — structure it however fits the work.
validations:
required: false
================================================
FILE: .github/dependabot.yml
================================================
version: 2
updates:
- package-ecosystem: 'github-actions'
directory: '/'
schedule:
interval: 'weekly'
- package-ecosystem: 'npm'
directory: '/'
schedule:
interval: 'weekly'
================================================
FILE: .github/labeler.yml
================================================
# Configuration for actions/labeler
# https://github.com/actions/labeler
blog:
- changed-files:
- any-glob-to-any-file:
- "blog/**"
documentation:
- changed-files:
- any-glob-to-any-file:
- "docs/docs/**"
================================================
FILE: .github/workflows/blog-preview.yml
================================================
name: Blog Preview
on:
pull_request:
types: [opened, synchronize, reopened, closed]
paths:
- "blog/**"
permissions:
contents: read
pull-requests: write
concurrency:
group: blog-preview-${{ github.event.pull_request.number }}
cancel-in-progress: true
jobs:
build-and-deploy:
# Explicitly refuse to run for fork PRs. Blog content is authored by maintainers
# pushing to branches in this repo — external contributors do not submit blog posts.
# This also prevents a fork from triggering a build that would fail on missing
# Cloudflare secrets anyway.
if: >-
github.event.action != 'closed' &&
github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v6
with:
submodules: recursive
fetch-depth: 0
- name: Build blog
uses: modelcontextprotocol/actions/hugo-build@main
with:
working-directory: blog
mode: preview
- name: Deploy preview
uses: modelcontextprotocol/actions/cloudflare-pages-preview/deploy@main
with:
directory: blog/public
project-name: mcp-blog-preview
api-token: ${{ secrets.CF_BLOG_PREVIEW_API_TOKEN }}
account-id: ${{ secrets.CF_BLOG_PREVIEW_ACCOUNT_ID }}
comment-title: "📰 Blog Preview Deployed"
comment-marker: "<!-- blog-preview-comment -->"
cleanup:
if: >-
github.event.action == 'closed' &&
github.event.pull_request.head.repo.full_name == github.repository
runs-on: ubuntu-latest
steps:
- uses: modelcontextprotocol/actions/cloudflare-pages-preview/cleanup@main
with:
project-name: mcp-blog-preview
api-token: ${{ secrets.CF_BLOG_PREVIEW_API_TOKEN }}
account-id: ${{ secrets.CF_BLOG_PREVIEW_ACCOUNT_ID }}
comment-marker: "<!-- blog-preview-comment -->"
================================================
FILE: .github/workflows/deploy-blog.yml
================================================
name: Deploy Hugo site to GitHub Pages
on:
push:
branches: ["main"]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
concurrency:
group: "pages"
cancel-in-progress: false
defaults:
run:
shell: bash
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v6
with:
submodules: recursive
fetch-depth: 0
- name: Setup Pages
id: pages
uses: actions/configure-pages@v5
- name: Build blog
uses: modelcontextprotocol/actions/hugo-build@main
with:
working-directory: blog
mode: production
base-url: https://blog.modelcontextprotocol.io/
- name: Upload artifact
uses: actions/upload-pages-artifact@v4
with:
path: ./blog/public
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
needs: build
steps:
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
================================================
FILE: .github/workflows/labeler.yml
================================================
name: Pull Request Labeler
on:
pull_request_target:
permissions:
contents: read
pull-requests: write
jobs:
label:
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v6
with:
sync-labels: false
================================================
FILE: .github/workflows/main.yml
================================================
on:
push:
branches:
- main
pull_request:
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: npm
- run: npm ci
- name: Check TypeScript definitions
run: npm run check:schema:ts
- name: Check schema.json files are up to date
run: npm run check:schema:json
- name: Check schema.mdx files are up to date
run: npm run check:schema:md
================================================
FILE: .github/workflows/markdown-format.yml
================================================
name: Markdown Format Check
on:
push:
paths:
- '**/*.md'
- '**/*.mdx'
pull_request:
paths:
- '**/*.md'
- '**/*.mdx'
jobs:
format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- name: Setup Node.js
uses: actions/setup-node@v6
with:
node-version: '24'
- name: Install dependencies
run: npm ci
- name: Check markdown formatting
run: npm run check:docs:format
- name: Check markdown links
run: npm run check:docs:links
================================================
FILE: .github/workflows/render-seps.yml
================================================
name: Render SEPs
on:
push:
branches:
- main
paths:
- "seps/**/*.md"
- "scripts/render-seps.ts"
pull_request:
paths:
- "seps/**/*.md"
- "scripts/render-seps.ts"
# Allow manual trigger
workflow_dispatch:
permissions:
contents: write
jobs:
render-seps:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-node@v6
with:
node-version: 24
cache: npm
- run: npm ci
# On PR, verify rendered docs are up to date (must run BEFORE generate)
- name: Verify SEPs are up to date
if: github.event_name == 'pull_request'
run: npm run check:seps
# On push to main, generate and commit any changes
- name: Render SEPs
if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
run: npm run generate:seps
- name: Check for changes
if: github.event_name == 'push' || github.event_name == 'workflow_dispatch'
id: changes
run: |
if [[ -n "$(git status --porcelain docs/community/seps/ docs/docs.json)" ]]; then
echo "has_changes=true" >> $GITHUB_OUTPUT
else
echo "has_changes=false" >> $GITHUB_OUTPUT
fi
- name: Commit changes
if: github.event_name == 'push' && github.ref == 'refs/heads/main' && steps.changes.outputs.has_changes == 'true'
run: |
git config --local user.email "github-actions[bot]@users.noreply.github.com"
git config --local user.name "github-actions[bot]"
git add docs/community/seps/ docs/docs.json
git commit -m "docs: auto-render SEPs documentation"
git push
================================================
FILE: .github/workflows/sep-lifecycle-manual.yml
================================================
name: SEP Lifecycle Automation (Manual)
on:
workflow_dispatch:
inputs:
issue_number:
description: 'Issue/PR number to process (leave empty for full sweep)'
type: string
required: false
dry_run:
description: 'Run in dry-run mode (no changes)'
type: boolean
default: true
env:
NODE_VERSION: '20'
jobs:
run-automation:
runs-on: ubuntu-latest
environment: sep-automation - production
permissions:
contents: read
issues: write
pull-requests: write
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Setup Node.js
uses: actions/setup-node@v6
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
cache-dependency-path: tools/sep-automation/package-lock.json
- name: Install dependencies
working-directory: tools/sep-automation
run: npm ci
- name: Build
working-directory: tools/sep-automation
run: npm run build
- name: Run SEP Lifecycle Automation
id: automation
working-directory: tools/sep-automation
run: |
if [[ "${{ github.event.inputs.dry_run }}" == "true" ]]; then
echo "::notice::Running in DRY RUN mode - no changes will be made"
else
echo "::warning::Running in PRODUCTION mode - changes will be applied!"
fi
if [[ -n "${{ github.event.inputs.issue_number }}" ]]; then
echo "Processing single issue #${{ github.event.inputs.issue_number }}"
npm start -- --issue ${{ github.event.inputs.issue_number }} 2>&1 | tee automation.log
else
echo "Running full sweep"
npm start 2>&1 | tee automation.log
fi
env:
# Use GitHub App for auth (has read:org for team membership checks)
APP_ID: ${{ secrets.APP_ID }}
APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
# Fallback to GITHUB_TOKEN if App not configured
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
MAINTAINERS_TEAM: core-maintainers
DRY_RUN: ${{ github.event.inputs.dry_run }}
DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
LOG_LEVEL: info
- name: Upload logs
uses: actions/upload-artifact@v7
if: always()
with:
name: automation-logs-manual-${{ github.run_id }}
path: tools/sep-automation/automation.log
retention-days: 30
================================================
FILE: .github/workflows/sep-lifecycle.yml
================================================
name: SEP Lifecycle Automation
on:
# Event-driven: react to SEP changes immediately
issues:
types: [labeled, unlabeled, assigned, unassigned, opened, reopened]
pull_request_target:
types: [labeled, unlabeled, assigned, unassigned, opened, reopened]
# Scheduled: weekly full sweep + Discord summary
schedule:
- cron: '0 9 * * 1' # Every Monday at 9 AM UTC
env:
NODE_VERSION: '20'
jobs:
check-sep:
# For issue/PR events, only run if it looks like a SEP
if: |
github.event_name == 'schedule' ||
contains(github.event.issue.labels.*.name, 'SEP') ||
contains(github.event.issue.labels.*.name, 'proposal') ||
contains(github.event.issue.labels.*.name, 'draft') ||
contains(github.event.issue.labels.*.name, 'in-review') ||
contains(github.event.issue.labels.*.name, 'accepted') ||
contains(github.event.pull_request.labels.*.name, 'SEP') ||
contains(github.event.pull_request.labels.*.name, 'proposal') ||
contains(github.event.pull_request.labels.*.name, 'draft') ||
contains(github.event.pull_request.labels.*.name, 'in-review') ||
contains(github.event.pull_request.labels.*.name, 'accepted') ||
contains(github.event.issue.title, 'SEP') ||
contains(github.event.pull_request.title, 'SEP')
runs-on: ubuntu-latest
outputs:
should_run: ${{ steps.check.outputs.should_run }}
issue_number: ${{ steps.check.outputs.issue_number }}
is_single: ${{ steps.check.outputs.is_single }}
steps:
- name: Determine run mode
id: check
run: |
if [[ "${{ github.event_name }}" == "schedule" ]]; then
echo "should_run=true" >> $GITHUB_OUTPUT
echo "issue_number=" >> $GITHUB_OUTPUT
echo "is_single=false" >> $GITHUB_OUTPUT
else
# Issue or PR event
ISSUE_NUMBER="${{ github.event.issue.number || github.event.pull_request.number }}"
echo "should_run=true" >> $GITHUB_OUTPUT
echo "issue_number=$ISSUE_NUMBER" >> $GITHUB_OUTPUT
echo "is_single=true" >> $GITHUB_OUTPUT
fi
run-automation:
needs: check-sep
if: needs.check-sep.outputs.should_run == 'true'
runs-on: ubuntu-latest
permissions:
contents: read
issues: write
pull-requests: write
steps:
- name: Checkout
uses: actions/checkout@v6
- name: Setup Node.js
uses: actions/setup-node@v6
with:
node-version: ${{ env.NODE_VERSION }}
cache: 'npm'
cache-dependency-path: tools/sep-automation/package-lock.json
- name: Install dependencies
working-directory: tools/sep-automation
run: npm ci
- name: Build
working-directory: tools/sep-automation
run: npm run build
- name: Run SEP Lifecycle Automation
id: automation
working-directory: tools/sep-automation
run: |
if [[ "${{ needs.check-sep.outputs.is_single }}" == "true" ]]; then
echo "Processing single issue #${{ needs.check-sep.outputs.issue_number }}"
npm start -- --issue ${{ needs.check-sep.outputs.issue_number }} 2>&1 | tee automation.log
else
echo "Running full sweep"
npm start 2>&1 | tee automation.log
fi
env:
# Use GitHub App for auth (has read:org for team membership checks)
APP_ID: ${{ secrets.APP_ID }}
APP_PRIVATE_KEY: ${{ secrets.APP_PRIVATE_KEY }}
# Fallback to GITHUB_TOKEN if App not configured
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
MAINTAINERS_TEAM: core-maintainers
DRY_RUN: 'false'
DISCORD_WEBHOOK_URL: ${{ secrets.DISCORD_WEBHOOK_URL }}
LOG_LEVEL: info
- name: Upload logs
uses: actions/upload-artifact@v7
if: always()
with:
name: automation-logs-${{ github.run_id }}
path: tools/sep-automation/automation.log
retention-days: 30
================================================
FILE: .github/workflows/sep-reminder.yml
================================================
name: SEP Review Reminder
on:
schedule:
# Every Wednesday at 10am PST (18:00 UTC)
- cron: "0 18 * * 3"
workflow_dispatch: # Allow manual triggering
permissions: {}
jobs:
discord-reminder:
runs-on: ubuntu-latest
if: github.repository == 'modelcontextprotocol/modelcontextprotocol'
steps:
- name: Post Discord reminder
run: |
curl -X POST "${{ secrets.DISCORD_MAINTAINER_WEBHOOK }}" \
-H "Content-Type: application/json" \
-d '{
"content": "@everyone 📋 **Weekly SEP Review Reminder**\n\nPlease ensure any SEPs that should be reviewed in the next **MCP Core Maintainer Meeting** are:\n\n1. Put into `in-review` state\n2. Added to the [meeting doc](https://docs.google.com/document/d/1annqJ2m4jNFOx6vU0FMnDSr6V3c5uN4TCT_uuZcZFh8/edit?tab=t.0#heading=h.9k72mrwd8fnr)\n\nFor SEP guidelines, see: https://modelcontextprotocol.io/community/sep-guidelines"
}'
================================================
FILE: .github/workflows/slash-commands.yml
================================================
name: Slash Commands
on:
issue_comment:
types: [created]
pull_request_target:
types: [opened, synchronize]
permissions:
pull-requests: write
issues: write
contents: read
actions: write
statuses: write
jobs:
# Parse and execute /lgtm, /hold, /unhold, /stageblog comment commands;
# invalidate approval when new commits are pushed.
handle:
if: >-
(github.event_name == 'issue_comment' && github.event.issue.pull_request) ||
(github.event_name == 'pull_request_target' && github.event.action == 'synchronize')
runs-on: ubuntu-latest
steps:
- uses: modelcontextprotocol/actions/slash-commands@main
with:
github-token: ${{ secrets.SLASH_COMMANDS_TOKEN }}
always-allow-teams: core-maintainers,lead-maintainers
stageblog-workflow: stage-blog.yml
# Merge-gate commit status. Mark `slash-commands/approval` as a required
# status check in branch protection. This job sets it pending on PR open
# and on every push; only the /lgtm handler in the job above writes success.
status:
if: github.event_name == 'pull_request_target'
runs-on: ubuntu-latest
steps:
- uses: modelcontextprotocol/actions/slash-commands/status@main
================================================
FILE: .github/workflows/stage-blog.yml
================================================
name: Stage Blog (fork PRs)
# Dispatched by the slash-commands workflow when an authorized maintainer
# comments /stageblog on a PR that touches blog/**. This lets fork PRs get a
# blog preview without granting them secret access on pull_request events.
#
# The head_sha input is pinned at the time the maintainer comments — DO NOT
# re-fetch the PR head, or a fork author could push malicious code between
# the maintainer's review and this build.
on:
workflow_dispatch:
inputs:
pr_number:
description: PR number to comment on
required: true
type: string
head_sha:
description: Exact commit SHA to build (pinned at /stageblog time)
required: true
type: string
permissions:
contents: read
pull-requests: write
concurrency:
group: stage-blog-${{ inputs.pr_number }}
cancel-in-progress: true
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout pinned SHA
uses: actions/checkout@v6
with:
ref: ${{ inputs.head_sha }}
submodules: recursive
fetch-depth: 0
- name: Build blog
uses: modelcontextprotocol/actions/hugo-build@main
with:
working-directory: blog
mode: preview
- name: Deploy preview
uses: modelcontextprotocol/actions/cloudflare-pages-preview/deploy@main
with:
directory: blog/public
project-name: mcp-blog-preview
api-token: ${{ secrets.CF_BLOG_PREVIEW_API_TOKEN }}
account-id: ${{ secrets.CF_BLOG_PREVIEW_ACCOUNT_ID }}
branch: pr-${{ inputs.pr_number }}
pr-number: ${{ inputs.pr_number }}
commit-sha: ${{ inputs.head_sha }}
comment-title: "📰 Blog Preview (staged via /stageblog)"
comment-marker: "<!-- stage-blog-comment -->"
comment-mode: repost
================================================
FILE: .gitignore
================================================
.claude/
node_modules/
.DS_Store
.idea/
.jj
================================================
FILE: .npmrc
================================================
registry = "https://registry.npmjs.org/"
================================================
FILE: .nvmrc
================================================
v24.2.0
================================================
FILE: .prettierignore
================================================
docs/specification/*/schema.md
docs/specification/*/schema.mdx
docs/registry/
================================================
FILE: .prettierrc.json
================================================
{
"printWidth": 140,
"tabWidth": 4,
"useTabs": false,
"semi": true,
"singleQuote": true,
"trailingComma": "none",
"bracketSpacing": true,
"bracketSameLine": false,
"proseWrap": "always",
"arrowParens": "avoid",
"overrides": [
{
"files": "**/*.md",
"options": {
"printWidth": 280
}
}
]
}
================================================
FILE: .prototools
================================================
================================================
FILE: AGENTS.md
================================================
# Model Context Protocol (MCP)
This repository contains the MCP specification, documentation, and blog.
## Documentation Structure
- `docs/` - Mintlify site (`npm run serve:docs`)
- `docs/docs/` - guides and tutorials
- `docs/specification/` - MCP specification (more formal, versioned)
- `blog/` - Hugo blog (`npm run serve:blog`)
### Documentation Guidelines
- When creating flowcharts, and graphs to visualize aspect of the protocol, use mermaid diagrams where
possible.
- When writing tables, ensure column headers and columns are aligned with whitespace.
- Before pushing or creating PR's ensure that `npm run prep` is free of warnings and errors.
## Specification Versioning
Specifications use **date-based versioning** (YYYY-MM-DD), not semantic versioning:
- `schema/[YYYY-MM-DD]/` and `docs/specification/[YYYY-MM-DD]/` - released versions
- `schema/draft/` and `docs/specification/draft/` - in-progress work
## Schema Generation
TypeScript files are the **source of truth** for the protocol schema:
- Edit: `schema/[version]/schema.ts`
- Generate JSON + docs: `npm run generate:schema`
- This creates both `schema/[version]/schema.json` and the Schema Reference document in `docs/specification/[version]/schema.mdx`
Always regenerate after editing schema files.
## Schema Examples
JSON examples live in `schema/[version]/examples/[TypeName]/`:
- Directory name = schema type (e.g., `Tool/`, `Resource/`)
- Files validate against their directory's type: `Tool/example-name.json` → Tool schema
- Referenced in `schema.ts` via `@includeCode` JSDoc tags
## Useful Commands
```bash
# Dev servers
npm run serve:docs # Local Mintlify docs server
npm run serve:blog # Local Hugo blog server
# Generation (run after editing source files)
npm run generate # Generate all (schema + SEPs)
npm run generate:schema # Generate JSON schemas + MDX from TypeScript
npm run generate:seps # Generate SEP documents
# Formatting
npm run format # Format all (docs + schema)
npm run format:docs # Format markdown/MDX files
npm run format:schema # Format schema TypeScript files
# Checks
npm run check # Run all checks
npm run check:schema # Check schema (TS, JSON, examples, MDX)
npm run check:docs # Check docs (format, comments, links)
npm run check:seps # Check SEP documents
# Workflow
npm run prep # Full prep before committing (check, generate, format)
```
## Issue Creation
Blank issues are disabled. `gh issue create` and the API bypass the template
chooser, so when filing via CLI or API you **must** use one of the forms in
`.github/ISSUE_TEMPLATE/` and fill in its required fields.
Before filing, check `.github/ISSUE_TEMPLATE/config.yml` — some categories
are redirected out of this repo entirely:
- **SEPs** are pull requests adding a file to `seps/`, not issues
- **SDK bugs** belong in the individual SDK repository
- **Claude MCP behavior** belongs in `anthropics/claude-ai-mcp`
## Commit Guidelines
- Do not include model names or details (e.g., "Claude", "Opus") in commit messages
================================================
FILE: ANTITRUST.md
================================================
This project is part of LF Projects, LLC. See the [LF Projects Antitrust Policy](https://lfprojects.org/policies/antitrust-policy/).
================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our community a
harassment-free experience for everyone, regardless of age, body size, visible or
invisible disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal appearance,
race, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse,
inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our community
include:
- Demonstrating empathy and kindness toward other people
- Being respectful of differing opinions, viewpoints, and experiences
- Giving and gracefully accepting constructive feedback
- Accepting responsibility and apologizing to those affected by our mistakes, and
learning from the experience
- Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
- The use of sexualized language or imagery, and sexual attention or advances of any kind
- Trolling, insulting or derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or email address, without
their explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional
setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in response to
any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments,
commits, code, wiki edits, issues, and other contributions that are not aligned to this
Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when an
individual is officially representing the community in public spaces. Examples of
representing our community include using an official e-mail address, posting via an
official social media account, or acting as an appointed representative at an online or
offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to
the community leaders responsible for enforcement at mcp-coc@anthropic.com. All
complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter
of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the
consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing clarity
around the nature of the violation and an explanation of why the behavior was
inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of actions.
**Consequence**: A warning with consequences for continued behavior. No interaction with
the people involved, including unsolicited interaction with those enforcing the Code of
Conduct, for a specified period of time. This includes avoiding interactions in community
spaces as well as external channels like social media. Violating these terms may lead to
a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including sustained
inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public communication
with the community for a specified period of time. No public or private interaction with
the people involved, including unsolicited interaction with those enforcing the Code of
Conduct, is allowed during this period. Violating these terms may lead to a permanent
ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community standards,
including sustained inappropriate behavior, harassment of an individual, or aggression
toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 2.0,
available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
================================================
FILE: CONTRIBUTING.md
================================================
# Contributing to Model Context Protocol
Thank you for your interest in contributing to the Model Context Protocol specification, schemas, or docs!
This document outlines how to contribute to this project.
Also see the [overall MCP communication guidelines in our docs](https://modelcontextprotocol.io/community/communication), which explains how and where discussions about changes happen.
## General prerequisites
The following software is required to work on the spec:
- Node.js 24 or above
- TypeScript
- TypeScript JSON Schema (for generating JSON schema)
- [Mintlify](https://mintlify.com/) (optional, for docs)
- nvm (optional, for managing Node versions)
### Getting Started
1. [Fork the repository](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)
2. Clone your fork:
```bash
git clone https://github.com/YOUR-USERNAME/modelcontextprotocol.git
cd modelcontextprotocol
```
3. Install dependencies:
```bash
nvm install # install correct Node version
npm install # install dependencies
```
4. Create a new branch:
```bash
git checkout -b feature/your-feature-name
```
## Schema changes
Schema changes go in `schema/draft/schema.ts`. To validate your changes, run:
```bash
npm run check:schema:ts
```
`schema/draft/schema.json` and `docs/specification/draft/schema.mdx` are generated from `schema/draft/schema.ts`; do not edit them directly. To generate them, run:
```bash
npm run generate:schema
```
## Documentation changes
Documentation is written in MDX format and in the [`docs`](./docs) directory.
You can preview documentation changes locally by running:
```bash
npm run serve:docs
```
And lint them with:
```bash
npm run check:docs
npm run format
```
> [!NOTE]
> You can run all schema/documentation
> changes at once with `npm run prep`.
## Blog changes
The blog is built using [Hugo](https://gohugo.io/installation/) and located in the [`blog`](./blog) directory.
To preview blog changes locally:
```bash
npm run serve:blog
```
### Documentation Guidelines
When contributing to the documentation:
- Keep content clear, concise, and technically accurate
- Follow the existing file structure and naming conventions
- Include code examples where appropriate
- Use proper MDX formatting and components
- Test all links and code samples
- You may run `npm run check:docs:links` to look for broken internal links.
- Use appropriate headings: "When to use", "Steps", and "Tips" for tutorials
- Place new pages in appropriate sections (concepts, tutorials, etc.)
- Update `docs.json` when adding new pages
- Follow existing file naming conventions (`kebab-case.mdx`)
- Include proper frontmatter in MDX files
## Specification Proposal Guidelines
Specification changes follow the [SEP process](https://modelcontextprotocol.io/community/sep-guidelines).
Before drafting a proposal, review the [MCP design principles](https://modelcontextprotocol.io/community/design-principles)
— proposals that align with these principles move faster through review.
The shortest summary: explore the problem space and validate that others share the problem,
build a prototype that demonstrates a solution, then write the SEP based on what the
prototype taught you.
## Submitting Changes
1. Push your changes to your fork
2. Submit a pull request to the main repository
3. Follow the pull request template
4. Wait for review
## AI Contributions
> [!IMPORTANT]
>
> If you are using **any kind of AI assistance** to contribute to Model Context Protocol,
> it must be disclosed in the pull request or issue.
We welcome and encourage the use of AI tools to help improve Model Context Protocol. Many valuable contributions
have been enhanced with AI assistance for code generation, issue detection, and feature definition.
That being said, if you are using any kind of AI assistance (e.g., agents such as Claude Code, ChatGPT)
while contributing to Model Context Protocol, **this must be disclosed in the pull request or issue**,
along with the extent to which AI assistance was used (e.g., documentation comments vs. code generation).
If your PR responses or comments are being generated by an AI, disclose that as well.
As an exception, trivial spacing or typo fixes don't need to be disclosed, so long as the changes are
limited to small parts of the code or short phrases.
An example disclosure:
> This PR was written primarily by Claude Code.
Or a more detailed disclosure:
> I consulted ChatGPT to understand the codebase but the solution
> was fully authored manually by myself.
Failure to disclose this is first and foremost rude to the human operators on the other end of the pull request,
but it also makes it difficult to determine how much scrutiny to apply to the contribution.
In a perfect world, AI assistance would produce equal or higher quality work than any human. That isn't the world
we live in today, and in most cases where human supervision or expertise is not in the loop, it's generating code
or changes that cannot be reasonably maintained or evolved.
### What we're looking for
When submitting AI-assisted contributions, please ensure they include:
- **Clear disclosure of AI use** - You are transparent about AI use and degree to which you're using it for the contribution
- **Human understanding** - You personally understand what the changes do
- **Clear rationale** - You can explain why the change is needed and how it fits within Model Context Protocol goals
- **Concrete evidence** - Include test cases, scenarios, or examples that demonstrate the improvement
- **Your own analysis** - Share your thoughts on the end-to-end experience
### What we'll close
We reserve the right to close submissions that appear to not follow the disclosure policy.
## License
By contributing, you agree that your code or specification contributions will be
licensed under the Apache License 2.0. Documentation contributions (excluding
specifications) are licensed under CC-BY 4.0. See the [LICENSE](LICENSE) file for
details.
## Security
Please review our [Security Policy](SECURITY.md) for reporting security issues.
================================================
FILE: GOVERNANCE.md
================================================
General Project Policies
Model Context Protocol has been established as Model Context Protocol a Series of LF Projects, LLC. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.
Model Context Protocol participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project.
Except as described below, all code and specification contributions to the project must be made using the Apache License, Version 2.0 (available here: [https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)) (the “Project License”).
All outbound code and specifications will be made available under the Project License. The Core Maintainers may approve the use of an alternative open license or licenses for inbound or outbound contributions on an exception basis.
All documentation (excluding specifications) will be made available under Creative Commons Attribution 4.0 International license, available at: https://creativecommons.org/licenses/by/4.0.
================================================
FILE: LICENSE
================================================
The MCP project is undergoing a licensing transition from the MIT License to the Apache License, Version 2.0 ("Apache-2.0"). All new code and specification contributions to the project are licensed under Apache-2.0. Documentation contributions (excluding specifications) are licensed under CC-BY-4.0.
Contributions for which relicensing consent has been obtained are licensed under Apache-2.0. Contributions made by authors who originally licensed their work under the MIT License and who have not yet granted explicit permission to relicense remain licensed under the MIT License.
No rights beyond those granted by the applicable original license are conveyed for such contributions.
---
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to the Licensor for inclusion in the Work by the copyright
owner or by an individual or Legal Entity authorized to submit on behalf
of the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
---
MIT License
Copyright (c) 2024-2025 Model Context Protocol a Series of LF Projects, LLC.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
---
Creative Commons Attribution 4.0 International (CC-BY-4.0)
Documentation in this project (excluding specifications) is licensed under
CC-BY-4.0. See https://creativecommons.org/licenses/by/4.0/legalcode for
the full license text.
================================================
FILE: MAINTAINERS.md
================================================
# MCP Maintainers
This document lists current maintainers in the Model Context Protocol project.
**Last updated:** February 2, 2026
## Lead Maintainers
- [David Soria Parra](https://github.com/dsp-ant)
- _[Justin Spahr-Summers](https://github.com/jspahrsummers) (currently inactive)_
## Core Maintainers
- [Caitie McCaffrey](https://github.com/CaitieM20)
- [Che Liu](https://github.com/pwwpche)
- [Den Delimarsky](https://github.com/localden)
- [Kurtis Van Gent](https://github.com/kurtisvg)
- [Nick Aldridge](https://github.com/000-000-000-000-000)
- [Nick Cooper](https://github.com/nickcoai)
- [Paul Carleton](https://github.com/pcarleton)
- [Peter Alexander](https://github.com/pja-ant)
## SDK Maintainers
### Java SDK
- [Christian Tzolov](https://github.com/tzolov)
- [Dariusz Jędrzejczyk](https://github.com/chemicL)
- [Daniel Garnier-Moiroux](https://github.com/Kehrlann)
- [Mark Pollack](https://github.com/markpollack)
### Ruby SDK
- [Topher Bullock](https://github.com/topherbullock)
- [Koichi Ito](https://github.com/koic)
- [Ateş Göral](https://github.com/atesgoral)
- [Jonathan Hefner](https://github.com/jonathanhefner)
### Swift SDK
- [Matt Zmuda](https://github.com/mattt)
- [Carl Peaslee](https://github.com/carlpeaslee)
- [Maksym Mova](https://github.com/movetz)
- [Stephen Tallent](https://github.com/stallent)
### Go SDK
- [Rob Findley](https://github.com/findleyr)
- [Jonathan Amsterdam](https://github.com/jba)
- [Sam Thanawalla](https://github.com/samthanawalla)
### C# SDK
- [Stephan Halter](https://github.com/halter73)
- [Mike Kistler](https://github.com/mikekistler)
- [Den Delimarsky](https://github.com/dend)
- [Eirik Tsarpalis](https://github.com/eiriktsarpalis)
- [Stephen Toub](https://github.com/stephentoub)
### Kotlin SDK
- [Leonid Stashevsky](https://github.com/e5l)
- [Sergey Ignatov](https://github.com/ignatov)
- [Konstantin Pavlov](https://github.com/kpavlov)
- [Pavel Gorgulov](https://github.com/devcrocod)
- [Briliantov Vadim](https://github.com/Ololoshechkin)
- [Sergei Dubov](https://github.com/sdubov)
- [Maria Tigina](https://github.com/tiginamaria)
### Python SDK
- [Inna Harper](https://github.com/ihrpr)
- [Jerome Swannack](https://github.com/jerome3o)
- [Marcelo Trylesinski](https://github.com/Kludex)
- [Max Isbey](https://github.com/maxisbey)
- [Felix Weinberger](https://github.com/felixweinberger)
### TypeScript SDK
- [Inna Harper](https://github.com/ihrpr)
- [Felix Weinberger](https://github.com/felixweinberger)
- [Olivier Chafik](https://github.com/ochafik)
- [Konstantin Konstantinov](https://github.com/KKonstantinov)
- [Matt Carey](https://github.com/mattzcarey)
### Rust SDK
- [Alex Hancock](https://github.com/alexhancock)
- [Michael Bolin](https://github.com/bolinfest)
- [Bradley Axen](https://github.com/baxen)
- [Jack Amadeo](https://github.com/jamadeo)
- [Michael Neale](https://github.com/michaelneale)
### PHP SDK
- [Kyrian Obikwelu](https://github.com/CodeWithKyrian)
- [Christopher Hertel](https://github.com/chr-hertel)
- [Fabien Potencier](https://github.com/fabpot)
- [Nicolas Grekas](https://github.com/nicolas-grekas)
- [Tobias Nyholm](https://github.com/Nyholm)
- [Roman Pronskiy](https://github.com/pronskiy)
## Project Maintainers
### use-mcp
- [Glen Maddern](https://github.com/geelen)
### Inspector
- [Cliff Hall](https://github.com/cliffhall)
- [Konstantin Konstantinov](https://github.com/KKonstantinov)
- [Ola Hungerford](https://github.com/olaservo)
- [Bob Dickinson](https://github.com/BobDickinson)
### Registry
- [Toby Padilla](https://github.com/toby)
- [Tadas Antanavicius](https://github.com/tadasant)
- [Adam Jones](https://github.com/domdomegg)
- [Radoslav (Rado) Dimitrov](https://github.com/rdimitrov)
- [Bob Dickinson](https://github.com/BobDickinson)
### MCPB (Model Context Protocol Bundle)
- [Alexander Sklar](https://github.com/asklar)
- [Adam Jones](https://github.com/domdomegg)
- [Joan Xie](https://github.com/joan-anthropic)
### Reference Servers
- [Ola Hungerford](https://github.com/olaservo)
- [Cliff Hall](https://github.com/cliffhall)
- [Tadas Antanavicius](https://github.com/tadasant)
- [Shaun Smith](https://github.com/evalstate)
- [Jonathan Hefner](https://github.com/jonathanhefner)
## Community Moderators
- [Ola Hungerford](https://github.com/olaservo)
- [Cliff Hall](https://github.com/cliffhall)
- [Shaun Smith](https://github.com/evalstate)
- [Jonathan Hefner](https://github.com/jonathanhefner)
- [Tadas Antanavicius](https://github.com/tadasant)
## Working Group & Interest Group Maintainers
[Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) are not required to have maintainers (they can be managed by informal facilitators), but maintainers may be appointed on an as-needed basis.
### Security Interest Group
- [Den Delimarsky](https://github.com/dend)
- [Paul Carleton](https://github.com/pcarleton)
- [Jenn Newton](https://github.com/jenn-newton)
### Authorization Interest Group
- [Aaron Parecki](https://github.com/aaronpk)
- [Darin McAdams](https://github.com/D-McAdams)
- [Paul Carleton](https://github.com/pcarleton)
### Client Implementor Interest Group
**Note:** These individuals serve as MCP protocol representatives for their respective clients. For client-specific issues, use the official support channels provided by each product.
- [Alex Hancock](https://github.com/alexhancock) - Goose
- [Ben Brandt](https://github.com/benbrandt) - Zed
- [Connor Peet](https://github.com/connor4312) - VS Code
- [Gabriel Peal](https://github.com/gpeal) - Codex
- [Jun Han](https://github.com/formulahendry) - GitHub Copilot for JetBrains
- [Tyler Leonhardt](https://github.com/TylerLeonhardt) - VS Code
- [Michael Feldstein](https://github.com/msfeldstein) - Cursor
### Financial Services Interest Group
- [Sambhav Kothari](https://github.com/sambhav)
- [Peder Holdgaard Pedersen](https://github.com/PederHP)
### Transports Interest Group
- [Kurtis Van Gent](https://github.com/kurtisvg)
- [Jonathan Hefner](https://github.com/jonathanhefner)
- [Shaun Smith](https://github.com/evalstate)
- [Harvey Tuch](https://github.com/htuch)
### Server Identity Working Group
- [David Soria Parra](https://github.com/dsp-ant)
- [Nick Cooper](https://github.com/nickcoai)
### Agents Working Group
- [Peter Alexander](https://github.com/pja-ant)
- [Luca Chang](https://github.com/LucaButBoring)
- [Inna Harper](https://github.com/ihrpr)
### MCP Apps Working Group
- [Liad Yosef](https://github.com/liady)
- [Ido Salomon](https://github.com/idosal)
### Primitive Grouping Interest Group
- [Tapan Chugh](https://github.com/chughtapan)
## About This Document
This document is updated by the MCP maintainers and reflects the current
governance structure. For more information about MCP governance, see our
[governance documentation](https://modelcontextprotocol.io/community/governance).
================================================
FILE: README.md
================================================
# Model Context Protocol (MCP)
_Just heard of MCP and not sure where to start? Check out our [documentation website](https://modelcontextprotocol.io)._
This repo contains the:
- MCP specification
- MCP protocol schema
- Official MCP documentation
The schema is [defined in TypeScript](schema/2025-11-25/schema.ts) first, but
[made available as JSON Schema](schema/2025-11-25/schema.json) as well, for wider
compatibility.
The official MCP documentation is built using Mintlify and available at
[modelcontextprotocol.io](https://modelcontextprotocol.io).
## Authors
The Model Context Protocol was created by David Soria Parra ([@dsp](https://github.com/dsp)) and Justin Spahr-Summers ([@jspahrsummers](https://github.com/jspahrsummers)).
## Contributing
See [CONTRIBUTING.md](./CONTRIBUTING.md).
## License
This project is licensed under the [MIT License](LICENSE).
================================================
FILE: SECURITY.md
================================================
# Security Policy
Thank you for helping keep the Model Context Protocol and its ecosystem secure.
## Reporting Security Issues
If you discover a security vulnerability in this repository, please report it through
the [GitHub Security Advisory process](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability)
for this repository.
Please **do not** report security vulnerabilities through public GitHub issues, discussions,
or pull requests.
## What to Include
To help us triage and respond quickly, please include:
- A description of the vulnerability
- Steps to reproduce the issue
- The potential impact
- Any suggested fixes (optional)
## Intended Behaviors and Trust Model
This section documents behaviors that are intentional design choices in MCP and are
**not** considered security vulnerabilities. Understanding these behaviors helps
developers build accurate threat models, enables security researchers to focus on
genuine vulnerabilities, and clarifies the trust boundaries within MCP for all
implementers.
### Trust Model
MCP is designed to enable AI applications to interact with external tools, data
sources, and services. The protocol operates under the following trust assumptions:
**MCP clients trust MCP servers they connect to.** When a user or application
configures an MCP client to connect to a server, the client trusts that server to
provide tools, resources, and prompts. The security of this trust relationship
depends on proper server selection and configuration by the user or administrator.
**Local MCP servers are trusted like any other software you install.** When you run a
local MCP server, you are trusting it with the same level of access as any other
application or package on your system. Just as you would evaluate the trustworthiness
of a library or tool before installing it, you should evaluate MCP servers before
running them.
**MCP servers trust the execution environment they run in.** Servers have access to
the resources available in their execution context. This is by design, as servers need
access to local files, databases, APIs, or other resources to provide their intended
functionality.
**Users and administrators are responsible for server selection.** MCP clients should
provide clear information about server capabilities, but the decision to connect to
and use a server rests with the user or administrator. Some clients may auto-connect
to certain servers based on configuration; users should review these settings.
### Behaviors That Are Not Vulnerabilities
The following behaviors are intentional features of MCP and are **not** eligible for
security vulnerability reports:
#### Command Execution for STDIO Transport
MCP clients using the STDIO transport launch MCP servers by executing commands. This
command execution is an intended feature, not a vulnerability:
- Clients execute the configured command to start the server process
- The server process runs with the same privileges as the client
- Command arguments specified in configuration are passed to the server
**This is expected behavior.** Users configure which servers to run, and the client
executes those configurations. Reports about "arbitrary command execution" via STDIO
transport configuration, whether in MCP client applications or SDKs, are not
vulnerabilities. Process spawning is a core feature of the STDIO transport mechanism.
#### Server Capabilities and Side Effects
MCP servers provide capabilities that may have significant effects on the system or
external services. These capabilities are features, not vulnerabilities:
**File system access:** Servers like the reference filesystem server intentionally
read, write, and list files within their configured scope. A filesystem server's
purpose is to provide file access to AI applications.
**Git and version control:** Servers providing git functionality can execute git
commands, which may include operations like resetting commits or force pushing. If you
grant an AI agent unrestricted access to git commands, it can perform any git
operation—this is not a vulnerability in the server.
**Database operations:** Servers may execute queries, modify data, or manage database
schemas based on their intended purpose.
**Network and API access:** Servers may make HTTP requests, call external APIs, or
interact with remote services.
**System commands:** Some servers are designed to execute system commands or scripts.
**This is expected behavior.** Servers that perform their documented functions are
working as intended. Reports about "server X can perform action Y" are not
vulnerabilities when Y is the server's intended purpose. The appropriate safeguards
and permissions for these capabilities are the responsibility of the user or
administrator deploying the server.
#### Resource Access Patterns
MCP resources expose data to clients. Servers may provide resources containing file
contents, database query results, API responses, or system information.
**This is expected behavior.** Resources are designed to provide context and data to
AI applications. The scope of accessible data is determined by server implementation
and configuration.
#### LLM-Driven Tool Invocation
When AI applications use MCP, the language model determines which tools to invoke
based on user requests and available tool descriptions. This means:
- The LLM may invoke tools in ways the user did not explicitly request
- Tool invocations depend on how the LLM interprets the user's intent
- Multiple tools may be invoked in sequence
**This is expected behavior.** LLM-driven tool selection is fundamental to how AI
applications use MCP. Reports about "LLM invoked unexpected tool" are not MCP
vulnerabilities, as they relate to LLM behavior and application-level controls.
### Developer and Operator Responsibilities
MCP's security model places certain responsibilities on developers and operators:
**Server developers are responsible for:**
- Implementing appropriate access controls within their servers
- Documenting the capabilities and permissions their servers require
- Validating inputs from clients before performing sensitive operations
- Following the principle of least privilege in server design
**Client developers are responsible for:**
- Providing clear information to users about server capabilities
- Implementing appropriate consent mechanisms before connecting to servers
- Displaying tool invocations and resource access to users when appropriate
- Sandboxing server execution where feasible
**Operators and users are responsible for:**
- Connecting only to trusted MCP servers
- Reviewing server configurations before deployment
- Understanding the capabilities of servers they enable
- Configuring appropriate access restrictions for their environment
For additional guidance on building and deploying secure MCP implementations, see the
[Security Best Practices](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices)
documentation.
### What Remains In Scope
The following categories **are** considered security vulnerabilities when they arise
from flaws in the MCP specification or official SDK implementations:
- **Protocol-level vulnerabilities**: Flaws in the MCP specification that enable
attacks regardless of implementation
- **Authentication/authorization bypasses**: Ways to access resources or invoke tools
without proper authorization
- **Implementation vulnerabilities**: Bugs in specific SDK implementations (buffer
overflows, injection flaws, etc.)
- **Sandbox escapes**: Breaking out of intended isolation boundaries explicitly
defined in the protocol or SDKs
- **Session hijacking**: Unauthorized access to another user's session
- **Token theft or leakage**: Vulnerabilities that expose access tokens
- **Cross-tenant access**: Accessing resources belonging to other users in
multi-tenant deployments
This list is not exhaustive.
### Reporting Guidelines
When evaluating whether to report a potential security issue:
1. **Check this document first.** If the behavior is listed as intended, it is not
a vulnerability.
2. **Consider the trust model.** If the issue requires the attacker to already have
access that the trust model assumes they have, it may not be a vulnerability.
3. **Focus on unexpected access.** Vulnerabilities typically involve accessing
resources or performing actions that should not be possible given the established
trust boundaries.
4. **Provide context.** If you believe you have found a genuine vulnerability,
explain how it violates the intended security boundaries.
================================================
FILE: blog/.gitignore
================================================
# Hugo default output directory
/public/
/resources/_gen/
/assets/jsconfig.json
# Hugo cache
.hugo_build.lock
# macOS
.DS_Store
================================================
FILE: blog/archetypes/default.md
================================================
---
title: '{{ replace .File.ContentBaseName "-" " " | title }}'
date: "{{ .Date }}"
draft: true
# One-sentence SEO summary. PaperMod emits this as BlogPosting.description
# and <meta name="description">. Without it, both fall back to the first ~70
# words of the post body.
description: ""
# PaperMod emits each entry as a schema.org Person in BlogPosting.author.
author:
- ""
tags: []
# Optional per-post image for JSON-LD and OpenGraph (falls back to site
# og-image.png). Place under static/posts/<slug>/ and reference relative to
# static/.
# cover:
# image: posts/{{ .File.ContentBaseName }}/cover.png
---
================================================
FILE: blog/assets/css/extended/custom.css
================================================
/* ─── Color tokens ───────────────────────────────────────────────────────── */
/* --link is the one brand accent. indigo-600 light / indigo-400 dark both
clear WCAG AA against the theme background. PaperMod renders prose links
with `box-shadow: 0 1px 0` in currentColor, which is invisible when link
text matches body text — this gives them a distinguishable hue. */
:root {
--link: #4f46e5;
--hairline: rgba(112, 112, 112, 0.08);
}
.dark {
--link: #818cf8;
--hairline: rgba(206, 206, 206, 0.08);
}
/* ─── Links ──────────────────────────────────────────────────────────────── */
.post-content a {
color: var(--link);
}
.post-content a code {
color: var(--link);
box-shadow: 0 -1px 0 var(--link) inset;
}
/* ─── Keyboard focus ─────────────────────────────────────────────────────── */
/* PaperMod zeroes outlines on #theme-toggle, .top-link, input, textarea with
no replacement. :focus-visible keeps mouse clicks ring-free while giving
keyboard/switch users a visible indicator. */
:focus-visible {
outline: 2px solid var(--primary);
outline-offset: 3px;
border-radius: 2px;
transition: outline-offset 0.1s ease-out;
}
#theme-toggle:focus-visible,
.top-link:focus-visible {
outline: 2px solid var(--primary);
outline-offset: 3px;
}
/* ─── Search box ─────────────────────────────────────────────────────────── */
/* Match the docs site's search affordance: 1px ~30% gray ring, 36px tall,
12px radius, 14px text, normal weight. PaperMod's default is a thick
2px --tertiary border with bold text. Focus indicator is the border-color
shift alone — no outline ring, which would make the box appear to jump
size given it's already 100% width. */
#searchbox input {
height: 36px;
padding: 0 14px;
font-size: 14px;
font-weight: normal;
background: var(--theme);
border: 1px solid rgba(112, 112, 112, 0.3);
border-radius: 12px;
transition: border-color 0.15s ease;
}
#searchbox input::placeholder {
color: var(--secondary);
}
#searchbox input:focus,
#searchbox input:focus-visible {
outline: none;
border-color: rgba(112, 112, 112, 0.5);
border-radius: 12px;
}
.dark #searchbox input {
border-color: rgba(206, 206, 206, 0.2);
}
.dark #searchbox input:focus,
.dark #searchbox input:focus-visible {
border-color: rgba(206, 206, 206, 0.4);
}
/* ─── Skip link ──────────────────────────────────────────────────────────── */
.skip-link {
position: absolute;
top: -100px;
left: 8px;
z-index: 100;
padding: 8px 16px;
background: var(--primary);
color: var(--theme);
border-radius: 4px;
transition: top 0.2s ease;
}
.skip-link:focus {
top: 8px;
}
/* ─── Homepage intro card ────────────────────────────────────────────────── */
/* PaperMod forces min-height: 320px regardless of content. With a two-line
intro that is ~240px of dead scroll before the first post card on mobile. */
.first-entry {
min-height: auto;
}
/* ─── Reading rhythm ─────────────────────────────────────────────────────── */
.post-content {
line-height: 1.7;
}
.post-content h2 {
margin-top: 56px;
}
.post-content h3 {
margin-top: 40px;
}
.post-title {
letter-spacing: -0.02em;
margin-bottom: 0;
}
/* PaperMod's spacing in the post header is uneven: title→description is 12px
(margin-bottom:2px + margin-top:10px), description→meta is 5px, meta→content
is --content-gap (20px). Normalize the intra-header gaps to the same 20px. */
.post-description {
margin: var(--content-gap) 0 0;
}
.post-header .post-meta {
margin-top: var(--content-gap);
}
/* PaperMod's .toc has margin: 0 2px 40px 2px — zero top (so byline→TOC is
already --content-gap via .post-header's margin-bottom) but 40px bottom. */
.toc {
margin-bottom: var(--content-gap);
}
/* PaperMod's .post-footer (the tags row) has margin-top: 56px. */
.post-footer {
margin-top: var(--content-gap);
}
/* ─── Card hover ─────────────────────────────────────────────────────────── */
@media (hover: hover) {
.post-entry {
transition: border-color 0.15s ease;
}
.post-entry:hover {
border-color: var(--primary);
}
}
/* ─── Archives page ──────────────────────────────────────────────────────── */
.archive-count {
display: inline-flex;
align-items: center;
justify-content: center;
min-width: 20px;
height: 20px;
padding: 0 7px;
margin-inline-start: 8px;
vertical-align: 3px;
font-size: 13px;
font-weight: normal;
font-variant-numeric: tabular-nums;
background: var(--code-bg);
border: 1px solid var(--border);
border-radius: 10px;
}
/* ─── Post footer tags ───────────────────────────────────────────────────── */
.post-tags a {
text-transform: lowercase;
}
/* ─── Header ─────────────────────────────────────────────────────────────── */
/* Match the docs site's framed layout: a hairline rule below the nav and
above the footer. modelcontextprotocol.io uses border-gray-500/5 on the
navbar and border-gray-100 on the footer — both nearly invisible until
you look for them. Nav link size/weight matches the docs site's
.nav-tabs (text-sm font-medium = 14px / 500). */
.header {
border-bottom: 1px solid var(--hairline);
}
/* modelcontextprotocol.io displays its wordmark at h-7 (28px); the effective
letter cap-height inside that image is ~18px. PaperMod's default 24px
.logo a text reads one size louder than the docs header. */
.logo a {
font-size: 18px;
font-weight: 500;
}
.logo a .logo-svg {
margin-inline-end: 8px;
vertical-align: -7px;
}
#menu a {
font-size: 14px;
font-weight: 500;
}
#menu a:hover {
color: var(--link);
}
/* ─── Buttons ────────────────────────────────────────────────────────────── */
/* Shared treatment for the homepage "All posts" link and the list-page
paginator. PaperMod's default .pagination a is an inverted high-contrast
pill (bg:--primary, color:--theme) — restyle to match .paginav and the
tag chips. */
.all-posts-link,
.pagination a {
display: inline-block;
padding: 8px 16px;
color: var(--primary);
font-size: 14px;
line-height: inherit;
background: var(--code-bg);
border: 1px solid var(--border);
border-radius: var(--radius);
transition: border-color 0.15s ease;
}
@media (hover: hover) {
.all-posts-link:hover,
.pagination a:hover {
border-color: var(--primary);
}
}
/* ─── Footer ─────────────────────────────────────────────────────────────── */
/* PaperMod's .footer is max-width constrained to the content column. The
::before rule escapes that box via the 100vw-centered trick so the
separator spans the full viewport like the header's does. */
/* width:100% — same flex-item fix as .main below. PaperMod's margin:auto +
max-width shrinks to content as a flex item; explicit width restores the
block-flow "cap at max-width, center" behavior. */
.footer {
position: relative;
padding-top: 24px;
width: 100%;
}
.footer::before {
content: '';
position: absolute;
top: 0;
left: 50%;
transform: translateX(-50%);
width: 100vw;
height: 1px;
background: var(--hairline);
}
/* PaperMod sets white-space:nowrap on .footer span:last-child for its short
"Powered by Hugo" line. Our copyright is two sentences — let it wrap.
Selector matches PaperMod's specificity (0,2,1) to actually override it. */
.footer > span:last-child {
display: block;
white-space: normal;
overflow-wrap: break-word;
}
.footer-nav {
margin-bottom: 8px;
}
.footer-nav a {
border-bottom: none;
}
.footer-nav a:hover {
color: var(--link);
border-bottom: none;
}
.footer-sep {
color: var(--border);
}
/* ─── Mobile ─────────────────────────────────────────────────────────────── */
@media screen and (max-width: 768px) {
/* "Model Context Protocol Blog" at 18px is ~216px of text. With the
glyph it's tight at phone widths, and .nav's flex-wrap means the
title can sit on its own line when the menu drops below — but the
title itself never wraps. Shrink it so both fit. */
.logo a {
font-size: 16px;
}
.logo a .logo-svg {
width: 24px;
height: 24px;
vertical-align: -6px;
}
/* .nav inherits the 60px desktop header-height as line-height. With three
stacked rows (logo, text nav, icons) that's 180px of header before any
padding. Tighten everything. */
.nav {
line-height: 40px;
padding-bottom: 8px;
}
/* PaperMod's #menu is white-space:nowrap + overflow-x:auto — a horizontal
scroller. With four nav items plus RSS/GitHub/LinkedIn icons plus the
theme toggle, it's wider than most phones. Let it wrap instead.
PaperMod spaces items with li+li margin-inline-start, which leaves the
visually-first item on a wrapped row indented — gap doesn't. */
#menu {
white-space: normal;
flex-wrap: wrap;
gap: 0 var(--gap);
overflow-x: visible;
line-height: 32px;
}
#menu li + li {
margin-inline-start: 0;
}
/* Text nav (Docs/Posts/Archives/Search) on one row, icon row below. */
.menu-break {
flex-basis: 100%;
height: 0;
}
/* Footer: eight links + separators wrap across 2–3 lines at phone width. */
.footer {
padding-top: 20px;
}
.footer-nav {
line-height: 2;
margin-bottom: 12px;
}
}
/* Hidden at desktop — icons sit inline after the text nav. */
.menu-break {
display: none;
}
@media screen and (max-width: 768px) {
.menu-break {
display: block;
}
}
/* ─── Sticky footer layout ───────────────────────────────────────────────── */
/* PaperMod sizes .main with calc(100vh - 60px - 60px), assuming a single-line
footer. Ours is taller (nav row, extra padding), so that calc overshoots
and forces a small scroll even when content fits the viewport. Flex column
on body lets the footer sit at the bottom regardless of its actual height.
100dvh avoids the mobile-address-bar jump; 100vh is the fallback. */
body {
display: flex;
flex-direction: column;
min-height: 100vh;
min-height: 100dvh;
}
/* .main has margin:auto + max-width. As a flex item, margin:auto makes it
shrink-to-fit then center (vs block flow where it just centers a capped
box). Explicit width:100% restores the block-flow behavior so pages like
/search/ don't start at placeholder-width and grow as results appear. */
.main {
flex: 1;
min-height: auto;
width: 100%;
}
/* ─── Page chrome ────────────────────────────────────────────────────────── */
/* Override list page background to white in light mode */
.list {
background: var(--theme);
}
/* Dark mode remains unchanged */
.dark.list {
background: var(--theme);
}
/* Mermaid diagram styling for dark mode */
.dark .mermaid {
filter: invert(0.85) hue-rotate(180deg);
}
/* Prevent awkward wrapping in post metadata. See https://github.com/adityatelange/hugo-PaperMod/issues/1789 */
.post-meta {
display: block !important;
}
.post-description {
color: var(--secondary);
font-style: italic;
}
/* Split prev/next post nav into two separate buttons (PaperMod joins them in one box) */
/* Match the 10px margin-bottom that .post-footer > * puts between the tags
row and these buttons, so the prev/next pair sits on the same grid. */
.paginav {
background: none;
border: none;
gap: 10px;
}
.paginav a {
background: var(--code-bg);
border: 1px solid var(--border);
padding: 10px 16px;
overflow: hidden;
}
.paginav a > span:not(.title) {
display: block;
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
}
/* PaperMod uses box-shadow as a fake underline, which runs the full width of
our now-block-level span. Swap to text-decoration so it tracks the text. */
.paginav span:hover:not(.title) {
box-shadow: none;
text-decoration: underline;
}
#menu a.menu-icon {
display: flex;
align-items: center;
height: 100%;
}
================================================
FILE: blog/content/_index.md
================================================
+++
title = 'Model Context Protocol Blog'
+++
================================================
FILE: blog/content/archives.md
================================================
---
title: "Archives"
layout: "archives"
---
================================================
FILE: blog/content/posts/2025-07-29-prompts-for-automation.md
================================================
---
title: "MCP Prompts: Building Workflow Automation"
date: "2025-08-04T18:00:00+01:00"
publishDate: "2025-08-04T18:00:00+01:00"
draft: false
description: A practical guide to building workflow automation with MCP prompts and resource templates, demonstrated through a meal planning example.
author:
- Inna Harper (Core Maintainer)
tags:
- automation
- mcp
- prompts
- tutorial
---
[MCP (Model Context Protocol)](https://modelcontextprotocol.io/specification/2025-06-18) prompts enable workflow automation by combining AI capabilities with structured data access. This post demonstrates how to build automations using MCP's [prompts](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts) and [resource templates](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates) through a practical example.
This guide demonstrates how MCP prompts can automate repetitive workflows. Whether you're interested in the MCP ecosystem or simply want to leverage AI for workflow automation, you'll learn how to build practical automations through a concrete meal planning example. No prior MCP experience needed—we'll cover the fundamentals before diving into implementation.
## The Problem: Time-Consuming Repetitive Tasks
Everyone has a collection of repetitive tasks that eat away at their productive hours. Common examples include applying code review feedback, generating weekly reports, updating documentation, or creating boilerplate code. These tasks aren't complex—they follow predictable patterns—but they're cumbersome and time-consuming. [MCP prompts](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts) were designed to help automate this kind of work.
MCP prompts offer more than command shortcuts. They're a primitive for building workflow automation that combines the flexibility of scripting with the intelligence of modern AI systems. This post explores how to build automations using MCP's prompt system, resource templates, and modular servers. I'll demonstrate these concepts through a meal planning automation I built, but the patterns apply broadly to any structured, repetitive workflow.
## Example: Automating Weekly Meal Planning
I needed to solve a recurring problem: planning weekly meals by cuisine to manage ingredients efficiently. The manual process involved selecting a cuisine, choosing dishes, listing ingredients, shopping, and organizing recipes—repetitive steps that took significant time each week.
So I decided to use MCP! By automating these steps, I could reduce the entire workflow to selecting a cuisine and receiving a complete meal plan with shopping list. (Any client that supports MCP prompts should work!)
1. **Select a prompt**
<img
src="/posts/images/prompts-list.png"
alt="MCP prompts list showing available automation commands"
/>
2. **Select a cuisine from a dropdown**
<img
src="/posts/images/prompts-suggestions.png"
alt="Dropdown showing cuisine suggestions as user types"
/>
3. **Done!**
The system generates a meal plan, shopping list, and even prints the shopping list and recipes.
<img
src="/posts/images/prompts-final-result.png"
alt="Final generated meal plan and shopping list output"
/>
Here we are focuses primarily on the Recipe Server with its prompts and resources. You can find the [printing server example here](https://github.com/ihrpr/mcp-server-tiny-print) (it works with a specific thermal printer model, but you could easily swap it for email, Notion, or any other output method). The beauty of separate servers is that you can mix and match different capabilities.
## Core Components
Let's dive into the three components that make this automation possible: [prompts](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts), [resources](https://modelcontextprotocol.io/specification/2025-06-18/server/resources), and [completions](https://modelcontextprotocol.io/specification/2025-06-18/server/utilities/completion). I'll show you how each works conceptually, then we'll implement them together.
### 1. Resource Templates
In MCP, [static resources](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-types) represent specific pieces of content with unique URIs—like `file://recipes/italian.md` or `file://recipes/mexican.md`. While straightforward, this approach doesn't scale well. If you have recipes for 20 cuisines, you'd need to define 20 separate resources, each with its own URI and metadata.
[Resource templates](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates) solve this through URI patterns with parameters, transforming static resource definitions into dynamic content providers.
For example, a template like `file://recipes/{cuisine}.md` might represent a set of resources like these:
- `file://recipes/italian.md` returns Italian recipes
- `file://recipes/mexican.md` returns Mexican recipes
This pattern extends beyond simple filtering. You can create templates for:
- Hierarchical data: `file://docs/{category}/{topic}`
- Git repository content: `git://repo/{branch}/path/{file}`
- Web resources: `https://api.example.com/users/{userId}/data`
- Query parameters: `https://example.com/{collection}?type={filter}`
For more details on URI schemes and resource templates, see the [MCP Resource specification](https://modelcontextprotocol.io/specification/2025-06-18/server/resources#resource-templates).
### 2. Completions
Nobody remembers exact parameter values. Is it "italian" or "Italian" or "it"? [Completions](https://modelcontextprotocol.io/specification/2025-06-18/server/utilities/completion) bridge this gap by providing suggestions as users type, creating an interface that feels intuitive rather than restrictive.
Different MCP clients present completions differently:
- VS Code shows a filterable dropdown
- Command-line tools might use fuzzy matching
- Web interfaces could provide rich previews
But the underlying data comes from your server, maintaining consistency across all clients.
### 3. Prompts: Commands That Evolve With Context
[Prompts](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts) are the entry points to your automation. They define what commands are available and can range from simple text instructions to rich, context-aware operations.
Let's see how prompts can evolve to handle increasingly sophisticated use cases:
**Basic prompt: Static instruction**
```
"Create a meal plan for a week"
```
This works, but it's generic. The AI will create a meal plan based on general knowledge.
**Adding parameters: Dynamic customization**
```
"Create a meal plan for a week using {cuisine} cuisine"
```
Now users can specify Italian, Mexican, or any other cuisine. The prompt adapts to user input, but still relies on the AI's general knowledge about these cuisines.
**Including resources: Your data**
Prompts can include resources to add context data beyond simple text instructions. This is crucial when you need the AI to work with your specific context rather than general knowledge.
In my meal planning example, I don't want generic recipes—I want the AI to use **my** collection of tested recipes that I know I like. Complex prompts make this possible by bundling prompt text with embedded resources.
Here's how it works:
1. **User selects a prompt** with parameters (e.g., "plan-meals" with cuisine="italian")
2. **Server returns** both instructional text AND resource references
3. **Client decides how to handle resources** - Applications might choose to select a subset of data using embeddings or keyword search, or pass the raw data directly to the model
4. **AI receives the context** and generates a response
In my example, VS Code attached the entire resource to the prompt, which worked great for this use case. The AI had access to all my Italian recipes when planning an Italian week, ensuring it only suggested dishes I actually had recipes for.
The key difference from simple prompts: instead of asking "Plan Italian meals" and getting generic suggestions, the AI works with your actual recipe collection, dietary preferences, and constraints.
<img
src="/posts/images/prompts-rendered-prompt.png"
alt="VS Code showing the rendered prompt with attached recipe resources"
/>
The recipe resources we've been using are **embedded resources** that have inline content from the server. According to the [MCP specification](https://modelcontextprotocol.io/specification/2025-06-18/server/prompts#data-types), prompts can also include other data types.
This enables advanced use cases beyond our text-based recipes, like design review prompts with screenshots or voice transcription services.
## Building the Recipe Server
Let's implement a complete MCP server that brings together all the concepts we've discussed. We'll start with the server setup and then implement each capability.
### Prerequisites
Before diving into the code, make sure you have:
1. **Node.js** (v18 or higher) and npm installed
2. **MCP SDK** installed:
```bash
npm install @modelcontextprotocol/sdk
```
3. **An MCP-compatible client with prompt and resource support**,like VS Code with the MCP extension
For this tutorial, I'll use the TypeScript SDK, but MCP also supports Python and other languages.
### Server Setup and Capabilities
First, let's create our MCP server:
```typescript
const server = new McpServer({
name: "favorite-recipes",
version: "1.0.0",
});
async function main() {
const transport = new StdioServerTransport();
await server.connect(transport);
}
main().catch((error) => {
console.error("Server error:", error);
process.exit(1);
});
```
### Implementing Resources
Next, let's register a resource template with completions.
```typescript
server.registerResource(
"recipes",
new ResourceTemplate("file://recipes/{cuisine}", {
list: undefined,
complete: {
cuisine: (value) => {
return CUISINES.filter((cuisine) => cuisine.startsWith(value));
},
},
}),
{
title: "Cuisine-Specific Recipes",
description: "Traditional recipes organized by cuisine",
},
async (uri, variables, _extra) => {
const cuisine = variables.cuisine as string;
if (!CUISINES.includes(cuisine)) {
throw new Error(`Unknown cuisine: ${cuisine}`);
}
const content = formatRecipesAsMarkdown(cuisine);
return {
contents: [
{
uri: uri.href,
mimeType: "text/markdown",
text: content,
},
],
};
},
);
```
### Implementing Prompts
Finally, let's register the prompt, which also has completions:
```typescript
server.registerPrompt(
"weekly-meal-planner",
{
title: "Weekly Meal Planner",
description:
"Create a weekly meal plan and grocery shopping list from cuisine-specific recipes",
argsSchema: {
cuisine: completable(z.string(), (value) => {
return CUISINES.filter((cuisine) => cuisine.startsWith(value));
}),
},
},
async ({ cuisine }) => {
const resourceUri = `file://recipes/${cuisine}`;
const recipeContent = formatRecipesAsMarkdown(cuisine);
return {
title: `Weekly Meal Planner - ${cuisine} Cuisine`,
description: `Weekly meal planner for ${cuisine} cuisine`,
messages: [
{
role: "user",
content: {
type: "text",
text: `Plan cooking for the week. I've attached the recipes from ${cuisine} cuisine.
Please create:
1. A 7-day meal plan using these recipes
2. An optimized grocery shopping list that minimizes waste by reusing ingredients across multiple recipes
3. Daily meal schedule with specific dishes for breakfast, lunch, and dinner
4. Preparation tips to make the week more efficient
5. Print Shopping list
Focus on ingredient overlap between recipes to reduce food waste.`,
},
},
{
role: "user",
content: {
type: "resource",
resource: {
uri: resourceUri,
mimeType: "text/markdown",
text: recipeContent,
},
},
},
],
};
},
);
```
## Running It Yourself
The [full code for the recipe server is available here](https://github.com/ihrpr/mcp-server-fav-recipes).
Follow VS Code's [documentation to set up the server](https://code.visualstudio.com/docs/copilot/chat/mcp-servers). Once a server is set up in VS Code, you can see its status, debug what's happening, and iterate quickly on your automations.
After the server is set up in VS Code, type "/" in chat and select the prompt.
<img
src="/posts/images/prompts-list.png"
alt="MCP prompts list showing available automation commands"
/>
## Extending Your Automations
MCP prompts open up exciting automation possibilities:
- **Prompt Chains**: Execute multiple prompts in sequence (plan meals → generate shopping list → place grocery order)
- **Dynamic Prompts**: Adapt based on available resources or time of year
- **Cross-Server Workflows**: Coordinate multiple MCP servers for complex automations
- **External Triggers**: Activate prompts via webhooks or schedules
The patterns demonstrated in meal planning apply to many domains:
- Documentation generation that knows your codebase
- Report creation with access to your data sources
- Development workflows that understand your project structure
- Customer support automations with full context
**Key takeaways:**
- MCP prompts can include dynamic resources, giving AI full context for tasks
- Resource templates enable scalable content serving without duplication
- Modular server architecture lets you mix and match capabilities
## Wrapping Up
This meal planning automation started as a simple desire to avoid rewriting shopping lists every week. It evolved into a complete system that handles meal planning, shopping lists, and recipe printing with just a few clicks.
MCP prompts provide practical tools to automate repetitive tasks. The modular architecture means you can start small—perhaps just automating one part of your workflow—and expand as needed. Whether you're automating documentation, reports, or meal planning, the patterns remain the same: identify repetitive tasks, build focused automations, and let the system handle the tedious parts.
================================================
FILE: blog/content/posts/2025-07-31-governance-for-mcp.md
================================================
---
title: "Building to Last: A New Governance Model for MCP"
date: "2025-07-31T00:00:00Z"
description: "Introducing MCP's formal governance model: Specification Enhancement Proposals (SEPs), a maintainer structure, and a community-driven process for evolving the protocol."
author:
- David Soria Parra (Lead Maintainer)
tags:
- announcement
- governance
- community
---
Since its open source release in November of 2024, the Model Context Protocol project has grown faster than we could have ever imagined. That's a wonderful problem to have, but with growth come growing pains. Our existing processes, which worked well for a small team, have started to show their limits.
Today, we're taking a big step to ensure MCP can continue to grow and thrive. We're introducing a formal governance model designed to bring clarity to the development process while preserving the collaborative, open source spirit that has made MCP successful.
## Specification Enhancement Proposals (SEPs)
One of the first major changes we're introducing is [Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines) (SEPs). This will be the primary mechanism for anyone to propose changes to MCP. SEPs are inspired by other projects, like [Python PEPs](https://peps.python.org/) or [Rust RFCs](https://github.com/rust-lang/rfcs). We aim to make the process for suggesting changes to Model Context Protocol as straightforward as possible:
1. Following the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines), submit a proposal as [a GitHub issue](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) to start the conversation.
2. Our maintainers and core maintainers regularly review proposals and tag SEPs for review and sponsorship. You can also reach out and collaborate with contributing folks on [Discord](https://discord.gg/6CSzBmMkjX) or [GitHub](https://github.com/modelcontextprotocol/modelcontextprotocol). Refer to [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) for a list of currently active maintainers and their focus areas.
3. Work with the sponsor and the MCP community to move your proposal through draft, review, and implementation stages.
SEPs provide a clear, documented path for evolving the protocol, ensuring that every major change is well-vetted by the community.
## Leadership Roles
The new model also establishes three types of leadership roles, ensuring both focused ownership and broad community representation:
- **Maintainers** manage specific components like SDKs, our documentation, and individual repositories.
- **Core Maintainers** guide the overall direction of the project and the evolution of the MCP specification.
- **Lead Maintainers** serve as the final decision-makers and ensure the project's long-term health.
All maintainers form the **MCP steering group**. To ensure a structured and timely review of incoming proposals, our core and lead maintainers will meet bi-weekly to review submitted [SEPs](#specification-enhancement-proposals-seps). Meeting notes and decisions will always be public. For example the [notes from the core maintainer meeting on July 23rd, 2025](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1061).
## Get Involved
We need your help to build the future of MCP, and everyone is welcome here. Whether you're a seasoned open source veteran or just curious about how to get started, there's a place for you in our community.
Many of our maintainers began with a single small contribution—sometimes just fixing a typo or asking a thoughtful question. Every journey starts somewhere, and we're excited to help you take your first step.
- **New Contributors**: Unsure where to begin? Start by helping with documentation, fixing bugs, or building out examples. Every contribution matters, and we're here to support you. Check out issues tagged with [`good first issue`](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22) - they're perfect for getting started, and you'll find friendly faces ready to help.
- **SDK Developers**: Have a favorite programming language? As MCP grows, we need your expertise to build and maintain the protocol SDKs. Your work could empower entire new communities to use MCP.
- **Documentation Writers**: Clear, comprehensive [documentation](https://modelcontextprotocol.io/introduction) is what turns a good project into a great one. If you love explaining things or making guides, your contributions will help others succeed.
- **Future Maintainers**: We believe in growing our team from within. The path to becoming a maintainer starts with consistent, quality contributions and a commitment to the project's success. Imagine yourself guiding new contributors and shaping the future of MCP.
No matter your background or experience, you belong here. Join our [Discord](https://discord.gg/6CSzBmMkjX) to connect with other contributors, ask questions, and find mentorship. Whether you're fixing a typo or proposing a major change to the protocol, your voice is valued and your efforts make a difference.
For all the details, please see our full [governance documentation](https://modelcontextprotocol.io/community/governance).
## Thank You
None of this would be possible without the incredible community that has rallied around MCP. From the early adopters who believed in the vision, to the developers building MCP clients and servers, to the maintainers dedicating their time and expertise. Every contribution has been essential to making the Model Context Protocol the success it is today.
You've helped us identify issues, improve documentation, build SDKs, create compelling examples, and push the boundaries of what's possible with platform integration. Your feedback, bug reports, feature requests, and code contributions have shaped MCP into something far better than we could have built alone.
As we embark on this next chapter with formal governance, we're more committed than ever to fostering the open, inclusive community that has made MCP thrive. Thank you for being part of this journey - we can't wait to see what we'll build together next.
================================================
FILE: blog/content/posts/2025-09-05-php-sdk.md
================================================
---
title: Announcing the Official PHP SDK for MCP
date: "2025-09-05T00:00:00Z"
description: The official PHP SDK for the Model Context Protocol is now generally available, built in collaboration with the PHP Foundation and Symfony.
author:
- David Soria Parra (Lead Maintainer)
- Christopher Hertel (Symfony)
- Roman Pronskiy (PHP Foundation)
tags:
- announcement
- community
---
The official [PHP SDK](https://github.com/modelcontextprotocol/php-sdk) for the Model Context Protocol is now generally available.
Built in collaboration with the [PHP Foundation](https://thephp.foundation/) and [Symfony](https://symfony.com/), the PHP SDK handles protocol details, so developers don’t have to worry about low-level mechanics and can focus on building their applications.
The initial release enables PHP developers to build MCP [servers](https://modelcontextprotocol.io/docs/learn/server-concepts), exposing [tools](https://modelcontextprotocol.io/docs/learn/server-concepts#tools-ai-actions), [prompts](https://modelcontextprotocol.io/docs/learn/server-concepts#prompts-interaction-templates), and [resources](https://modelcontextprotocol.io/docs/learn/server-concepts#resources-context-data) to AI applications. Support for PHP applications to act as MCP [clients](https://modelcontextprotocol.io/docs/learn/client-concepts) will follow.
The PHP SDK now joins 9 other [officially supported language SDKs](https://modelcontextprotocol.io/docs/sdk) in the MCP ecosystem, making it easier for developers everywhere to adopt MCP in their preferred language.
## Get involved
The PHP SDK is now open to the community to install, test, and contribute:
- SDK repo: [modelcontextprotocol/php-sdk](https://github.com/modelcontextprotocol/php-sdk)
- Composer package: [mcp/sdk](https://packagist.org/packages/mcp/sdk)
We welcome your feedback and contribution, including issues, documentation improvements, and pull requests. Framework-specific integrations and real-world examples are also particularly valuable.
## Thanks to the MCP community
This release consolidates earlier community work into a single, trusted implementation. The SDK is maintained by the [Symfony](https://symfony.com/) team, with [Kyrian Obikwelu](https://github.com/CodeWithKyrian) joining as a maintainer based on his previous [PHP-MCP](https://github.com/php-mcp) work. The [PHP Foundation](https://thephp.foundation/) helped to coordinate the initiative with support from the members of MCP steering group.
Thank you to all involved in bringing PHP to the MCP ecosystem.
================================================
FILE: blog/content/posts/2025-09-08-mcp-registry-preview.md
================================================
---
title: Introducing the MCP Registry
date: "2025-09-08T00:00:00Z"
description: "Launching the MCP Registry in preview: an open catalog and API for discovering publicly available MCP servers."
author:
- David Soria Parra (Lead Maintainer)
- Adam Jones (Registry Maintainer)
- Tadas Antanavicius (Registry Maintainer)
- Toby Padilla (Registry Maintainer)
- Theodora Chu (MCP PM at Anthropic)
tags:
- announcement
- community
---
Today, we're launching the Model Context Protocol (MCP) Registry—an open catalog and API for publicly available MCP servers to improve discoverability and implementation. By standardizing how servers are distributed and discovered, we’re expanding their reach while making it easier for clients to get connected.
The MCP Registry is now available in preview. To get started:
- **Add your server** by following our guide on [Adding Servers to the MCP Registry](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx) (for server maintainers)
- **Access server data** by following our guide on [Accessing MCP Registry Data](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) (for client maintainers)
# Single source of truth for MCP servers
In March 2025, we shared that we wanted to build a central registry for the MCP ecosystem. Today we are announcing that we’ve launched [https://registry.modelcontextprotocol.io](https://registry.modelcontextprotocol.io) as the official MCP Registry. As part of the MCP project, the MCP Registry, as well as a parent [OpenAPI specification](https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/official-registry-api.md), are open source—allowing everyone to build a compatible sub-registry.
Our goal is to standardize how servers are distributed and discovered, providing a primary source of truth that sub-registries can build upon. In turn, this will expand server reach and help clients find servers more easily across the MCP ecosystem.
## Public and private sub-registries
In building a central registry, it was important to us not to take away from existing registries that the community and companies have built. The MCP Registry serves as a primary source of truth for publicly available MCP servers, and organizations can choose to [create sub-registries](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) based on custom criteria. For example:
**Public subregistries** like opinionated “MCP marketplaces” associated with each MCP client are free to augment and enhance data they ingest from the upstream MCP Registry. Every MCP end-user persona will have different needs, and it is up to the MCP client marketplaces to properly serve their end-users in opinionated ways.
**Private subregistries** will exist within enterprises that have strict privacy and security requirements, but the MCP Registry gives these enterprises a single upstream data source they can build upon. At a minimum, we aim to share API schemas with these private implementations so that associated SDKs and tooling can be shared across the ecosystem.
In both cases, the MCP Registry is the starting point – it’s the centralized location where MCP server maintainers publish and maintain their self-reported information for these downstream consumers to massage and deliver to their end-users.
## Community-driven mechanism for moderation
The MCP Registry is an official MCP project maintained by the registry working group and permissively licensed. Community members can submit issues to flag servers that violate the MCP [moderation guidelines](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/moderation-policy.mdx)—such as those containing spam, malicious code, or impersonating legitimate services. Registry maintainers can then denylist these entries and retroactively remove them from public access.
# Getting started
To get started:
- **Add your server** by following our guide on [Adding Servers to the MCP Registry](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/quickstart.mdx) (for server maintainers)
- **Access server data** by following our guide on [Accessing MCP Registry Data](https://github.com/modelcontextprotocol/registry/blob/main/docs/modelcontextprotocol-io/registry-aggregators.mdx) (for client maintainers)
This preview of the MCP Registry is meant to help us improve the user experience before general availability and does not provide data durability guarantees or other warranties. We advise MCP adopters to watch development closely as breaking changes may occur before the registry is made generally available.
As we continue to develop the registry, we encourage feedback and contributions on the [modelcontextprotocol/registry GitHub repository](https://github.com/modelcontextprotocol/registry): Discussion, Issues, and Pull Requests are all welcome.
# Thanks to the MCP community
The MCP Registry has been a collaborative effort from the beginning and we are incredibly grateful for the enthusiasm and support from the broader developer community.
In February 2025, it began as a grassroots project when MCP creators [David Soria Parra](https://github.com/dsp-ant) and [Justin Spahr-Summers](https://github.com/jspahrsummers) asked the [PulseMCP](https://www.pulsemcp.com/) and [Goose](https://block.github.io/goose/) teams to help build a centralized community registry. Registry Maintainer [Tadas Antanavicius](https://github.com/tadasant) from [PulseMCP](https://www.pulsemcp.com/) spearheaded the initial effort in collaboration with [Alex Hancock](https://github.com/alexhancock) from [Block](https://block.xyz/). They were soon joined by Registry Maintainer [Toby Padilla](https://github.com/toby), Head of MCP at [GitHub](https://github.com/), and more recently, [Adam Jones](https://github.com/domdomegg) from [Anthropic](https://www.anthropic.com/) joined as Registry Maintainer to drive the project towards the launch today. The [initial announcement](https://github.com/modelcontextprotocol/registry/discussions/11) of the MCP Registry's development lists 16 contributing individuals from at least 9 different companies.
Many others made crucial contributions to bring this project to life: [Radoslav Dimitrov](https://github.com/rdimitrov) from [Stacklok](https://stacklok.com/), [Avinash Sridhar](https://github.com/sridharavinash) from [GitHub](https://github.com/), [Connor Peet](https://github.com/connor4312) from [VS Code](https://code.visualstudio.com/), [Joel Verhagen](https://github.com/joelverhagen) from [NuGet](https://www.nuget.org/), [Preeti Dewani](https://github.com/pree-dew) from [Last9](https://last9.io/), [Avish Porwal](https://github.com/Avish34) from [Microsoft](https://www.microsoft.com/), [Jonathan Hefner](https://github.com/jonathanhefner), and many Anthropic and GitHub employees that provided code reviews and development support. We are also grateful to everyone on the [Registry's contributors log](https://github.com/modelcontextprotocol/registry/graphs/contributors) and those who participated in [discussions and issues](https://github.com/modelcontextprotocol/registry).
We deeply appreciate everyone investing in this foundational open source infrastructure. Together, we're helping developers and organizations worldwide to build more reliable, context-aware AI applications. On behalf of the MCP community, thank you.
================================================
FILE: blog/content/posts/2025-09-26-mcp-next-version-update.md
================================================
---
title: Update on the Next MCP Protocol Release
date: "2025-09-26T10:00:00-08:00"
draft: false
description: An update on the timeline and priorities for the next Model Context Protocol specification version
author:
- David Soria Parra
tags:
- mcp
- protocol
- roadmap
- community
---
**Update (November 11, 2025):** The specification release candidate (RC) date has been shifted from November 11th to **November 14th, 2025**. The specification release date remains to be **November 25th, 2025**.
## Release Timeline
The next version of the Model Context Protocol specification will be released on **November 25th, 2025**, with a release candidate (RC) available on **November 11th, 2025**.
We're building in a 14-day RC validation window so client implementors and SDK maintainers can thoroughly test the protocol changes. This approach gives us the focused time we need to deliver critical improvements while applying our [new governance model](https://modelcontextprotocol.io/community/governance) to the process.
## Summer Progress
Our last spec was released on June 18, 2025, and focused on structured tool outputs, OAuth-based authorization, elicitation for server-initiated user interactions, and improved security best practices.
Since then, we’ve focused on establishing additional foundations for the MCP ecosystem:
### Formal Governance Structures
We established a [formal governance model for MCP](https://modelcontextprotocol.io/community/governance), including defined roles and decision-making mechanisms. We also developed the [Specification Enhancement Proposal (SEP)](https://modelcontextprotocol.io/community/sep-guidelines) process to provide clear guidelines for contributing specification changes.
Our goal is transparency—making decision-making procedures clear and accessible to everyone. Like any new system serving a fast-evolving community, our governance model is still finding its footing. We're actively refining it as both the protocol and community continue to grow.
### Working Groups
We've launched [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) to foster community collaboration. These groups serve multiple purposes:
- Provide clear entry points for new contributors
- Empower community members to lead initiatives in their areas of expertise
- Distribute ownership across the ecosystem rather than concentrating it among core maintainers
We're developing governance structures that will grant these groups greater autonomy in decision-making and implementation. This distributed approach ensures the protocol can grow to meet community needs while maintaining quality and consistency across different domains.
### Registry Development
In September, we [launched the MCP Registry preview](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/)—an open catalog and API for indexing and discovery of MCP servers. The Registry serves as the single source of truth for available MCP servers, supporting both public and private sub-registries that organizations can customize for their specific needs.
Building the MCP Registry has been a true community effort. Any MCP client can consume registry content via the native API or through third-party registry aggregators, making it easier for users to discover and integrate MCP servers into their AI workflows.
## Priority Areas for the Next Release
With governance and infrastructure foundations in place, we're focusing on five key protocol improvements identified by our working groups.
### Asynchronous Operations
Currently, MCP is built around mostly synchronous operations—when you call a tool, everything stops and waits for it to finish. That works great for quick tasks, but what about operations that take minutes or hours?
The Agents Working Group is adding async support, allowing servers to kick off long-running tasks while clients can check back later for results. You can follow the progress in [SEP-1391](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1391).
### Statelessness and Scalability
As organizations deploy MCP servers at enterprise scale, we're seeing new requirements emerge. Current implementations often need to remember things between requests, which makes horizontal scaling across multiple server instances challenging.
While [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-03-26/basic/transports#streamable-http) provides some stateless support, pain points remain around server startup and session handling. The Transport Working Group is smoothing out these rough edges, making it easier to run MCP servers in production while keeping simple upgrade paths for teams who want more sophisticated stateful features.
### Server Identity
Today, if you want to know what an MCP server can do, you have to connect to it first. This makes it difficult for clients to browse available servers or for systems like our registry to automatically catalog capabilities.
We're solving this by letting servers advertise themselves through [`.well-known` URLs](https://en.wikipedia.org/wiki/Well-known_URI)—an established standard for providing metadata. Think of it as a server's business card that anyone can read without having to knock on the door first. This will make discovery much more intuitive for every MCP consumer.
### Official Extensions
As MCP has grown, we've noticed patterns emerging for specific industries and use cases—valuable implementations that don't necessarily belong in the core protocol specification.
Rather than leaving everyone to reinvent the wheel, we're officially recognizing and documenting the most popular protocol extensions. This curated collection of proven patterns will give developers building for specialized domains like healthcare, finance, or education a solid starting point instead of building every custom integration from scratch.
### SDK Support Standardization
Choosing an MCP SDK today can be challenging—it's hard to gauge the level of support or spec compliance you'll get. Some SDKs are lightning-fast with updates, while others might lag behind feature-wise.
We're introducing a clear tiering system for SDKs. You'll know exactly what you're signing up for before committing to a dependency, based on factors like specification compliance speed, maintenance responsiveness, and feature completeness.
## Call for Contributors
MCP is only as strong as the community behind it. Whether you're an individual developer passionate about building SDKs or a company looking to invest in the ecosystem, we need your help in several key areas.
### SDK Maintenance
- [**TypeScript SDK**](https://github.com/modelcontextprotocol/typescript-sdk) - Needs additional maintainers for feature development and bug fixes
- [**Swift SDK**](https://github.com/modelcontextprotocol/swift-sdk) - Requires attention for Apple ecosystem support
- [Other language SDKs](https://modelcontextprotocol.io/docs/sdk) welcome continued contributions
### Tooling
- [**Inspector**](https://github.com/modelcontextprotocol/inspector) - Development and maintenance of debugging tools for MCP server developers
- [**Registry**](https://github.com/modelcontextprotocol/registry) - Backend API and CLI development; **Go expertise would be particularly welcome**
## Input from Client Developers
We talk a lot about MCP servers, but clients are equally important—they're the bridge connecting users to the entire MCP ecosystem. If you're building an MCP client, you're seeing the protocol from a unique angle, and we need that perspective embedded in the protocol design.
Your real-world experience with implementation challenges, performance bottlenecks, and user needs directly shapes where the protocol should go next. Whether it's feedback on existing capabilities or ideas for streamlining the developer experience, we want to hear from you.
Join us in the `#client-implementors` working group channel in the [MCP Discord](https://modelcontextprotocol.io/community/communication).
## Looking Ahead
With governance structures and working groups in place, we're better positioned to tackle major protocol improvements efficiently while ensuring everyone has a voice in the process. The foundational work we've done this summer gives us a solid base to build from.
The improvements coming in November—async operations, better scalability, server discovery, and standardized extensions—will help MCP become a stronger backbone for production AI integrations. But we can't do it alone.
MCP's strength has always been that it's an **open protocol built by the community, for the community**. We're excited to keep building it together.
Thank you for your continued support, and we look forward to sharing more soon.
================================================
FILE: blog/content/posts/2025-11-03-using-server-instructions.md
================================================
---
title: "Server Instructions: Giving LLMs a user manual for your server"
date: "2025-11-03T00:00:00+00:00"
publishDate: "2025-11-03T00:00:00+00:00"
draft: false
description: How server instructions give LLMs the context they need to use your MCP server's tools effectively — an underused protocol feature with outsized impact.
author:
- Ola Hungerford (Maintainer)
tags:
- automation
- mcp
- server instructions
- tools
---
Many of us are still exploring the nooks and crannies of MCP and learning how to best use the building blocks of the protocol to enhance agents and applications. Some features, like [Prompts](https://blog.modelcontextprotocol.io/posts/2025-07-29-prompts-for-automation/), are frequently implemented and used within the MCP ecosystem. Others may appear a bit more obscure but have a lot of influence on how well an agent can interact with an MCP server. **Server instructions** fall in the latter category.
## The Problem
Imagine you're a Large Language Model (LLM) who just got handed a collection of tools from a database server, a file system server, and a notification server to complete a task. They might have already been carefully pre-selected or they might be more like what my workbench looks like in my garage - a mishmash of recently-used tools.
Now let's say that the developer of the database server has pre-existing knowledge or preferences about how to best use their tools, as well as more background information about the underlying systems that power them.
Some examples could include:
- "Always use `validate_schema` → `create_backup` → `migrate_schema` for safe database migrations"
- "When using the `export_data` tool, the file system server's `write_file` tool is required for storing local copies"
- "Database connection tools are rate limited to 10 requests per minute"
- "If `create_backup` fails, check if the notification server is connected before attempting to send alerts"
- "Only use `request_preferences` to ask the user for settings if elicitation is supported. Otherwise, fall back to using default configuration"
So now our question becomes: what's the most effective way to share this contextual knowledge?
## Solutions
One solution could be to include extra information in every tool description or prompt provided by the server. Going back to the physical tool analogy, however: you can only depend on "labeling" each tool if there is enough space to describe them. A model's context window is limited - there's only so much information you can fit into that space. Even if all those labels can fit within your model's context window, the more tokens you cram into that space, the more challenging it becomes for models to follow them all.
Alternatively, relying on prompts to give common instructions means that:
- The prompt always needs to be selected by the user, and
- The instructions are more likely to get lost in the shuffle of other messages.
It's like having a pile of notes on my garage workbench, each trying to explain how different tools relate to each other. While you might find the right combination of notes, you'd rather have a single, clear manual that explains how everything works together.
Similarly, for global instructions that you want the LLM to follow, it's best to inject them into the model's system prompt instead of including them in multiple tool descriptions or standalone prompts.
This is where **server instructions** come in. [Server instructions](https://modelcontextprotocol.io/specification/draft/schema#initializeresult) give the server a way to inject information that the LLM should always read in order to understand how to use the server - independent of individual prompts, tools, or messages.
### A Note on Implementation Variability
Because server instructions may be injected into the system prompt, they should be written with caution and diligence. No instructions are better than poorly written instructions.
Additionally, the exact way that the MCP host uses server instructions is up to the implementer, so it's not always guaranteed that they will be injected into the system prompt. It's always recommended to evaluate a client's behavior with your server and its tools before relying on this functionality.
We will get deeper into both of these considerations with concrete examples.
## Real-World Example: Optimizing GitHub PR Reviews
I tested server instructions using the official [GitHub MCP server](https://github.com/github/github-mcp-server) to see if they could improve how models handle complex workflows. Even with advanced features like toolsets, models may struggle to consistently follow optimal multi-step patterns without explicit guidance.
### The Problem: Detailed Pull Request Reviews
One common use case where I thought instructions could be helpful is when asking an LLM to "Review pull request #123." Without more guidance, a model might decide to over-simplify and use the `create_and_submit_pull_request_review` tool to add all review feedback in a single comment. This isn't as helpful as leaving multiple inline comments for a detailed code review.
### The Solution: Workflow-Aware Instructions
One solution I tested with the GitHub MCP server is to add instructions based on enabled toolsets. My hypothesis was that this would improve the consistency of workflows across models while still ensuring that I was only loading relevant instructions for the tools I wanted to use. Here is an example of what I added if the `pull_requests` toolset is enabled:
```go
func GenerateInstructions(enabledToolsets []string) string {
var instructions []string
// Universal context management - always present
baseInstruction := "GitHub API responses can overflow context windows. Strategy: 1) Always prefer 'search_*' tools over 'list_*' tools when possible, 2) Process large datasets in batches of 5-10 items, 3) For summarization tasks, fetch minimal data first, then drill down into specifics."
// Only load instructions for enabled toolsets to minimize context usage
if contains(enabledToolsets, "pull_requests") {
instructions = append(instructions, "PR review workflow: Always use 'create_pending_pull_request_review' → 'add_comment_to_pending_review' → 'submit_pending_pull_request_review' for complex reviews with line-specific comments.")
}
return strings.Join(append([]string{baseInstruction}, instructions...), " ")
}
```
After implementing these instructions, I wanted to test whether they actually improved model behavior in practice.
### Measuring Effectiveness: Quantitative Results
To validate the impact of server instructions, I ran a simple controlled evaluation in Visual Studio Code comparing model behavior with and without the PR review workflow instruction. Using 40 GitHub PR review sessions on the same set of code changes, I measured whether models followed the optimal three-step workflow.
I used the following tool usage pattern to differentiate between successful and unsuccessful reviews:
- **Success:** `create_pending_pull_request_review` → `add_comment_to_pending_review` → `submit_pending_pull_request_review`
- **Failure:** Single-step `create_and_submit_pull_request_review` OR no review tools used. (Sometimes the model decided just to summarize feedback but didn't leave any comments on the PR.)
You can find more setup details and raw data from this evaluation in [my sample MCP Server Instructions repo](https://github.com/olaservo/mcp-server-instructions-demo).
For this sample of chat sessions, I got the following results:
| Model | With Instructions | Without Instructions | Improvement |
| ------------------- | ----------------- | -------------------- | ----------- |
| **GPT-5-Mini** | 8/10 (80%) | 2/10 (20%) | **+60%** |
| **Claude Sonnet-4** | 9/10 (90%) | 10/10 (100%) | N/A |
| **Overall** | 17/20 (85%) | 12/20 (60%) | **+25%** |
These results suggest that while some models naturally gravitate toward optimal patterns, others benefit significantly from explicit guidance. This variability makes server instructions particularly valuable for ensuring consistent behavior across different models and client implementations.
You can check out the latest server instructions in the [GitHub MCP server repo](https://github.com/github/github-mcp-server/blob/main/pkg/github/instructions.go), which now includes this PR workflow as well as other hints for effective tool usage.
## Implementing Server Instructions: General Tips For Server Developers
One key to good instructions is focusing on **what tools and resources don't convey**:
1. **Capture cross-feature relationships**:
```json
{
"instructions": "Always call 'authenticate' before any 'fetch_*' tools. The 'cache_clear' tool invalidates all 'fetch_*' results."
}
```
2. **Document operational patterns**:
```json
{
"instructions": "For best performance: 1) Use 'batch_fetch' for multiple items, 2) Check 'rate_limit_status' before bulk operations, 3) Results are cached for 5 minutes."
}
```
3. **Specify constraints and limitations**:
```json
{
"instructions": "File operations limited to workspace directory. Binary files over 10MB will be rejected. Rate limit: 100 requests/minute across all tools."
}
```
4. **Write model-agnostic instructions**:
Keep instructions factual and functional rather than assuming specific model behaviors. Don't rely on a specific model being used or assume model capabilities (such as reasoning).
### Anti-Patterns to Avoid
**Don't repeat tool descriptions**:
```json
// Bad - duplicates what's in tool.description
"instructions": "The search tool searches for files. The read tool reads files."
// Good - adds relationship context
"instructions": "Use 'search' before 'read' to validate file paths. Search results expire after 10 minutes."
```
**Don't include marketing or superiority claims**:
```json
// Bad
"instructions": "This is the best server for all your needs! Superior to other servers!"
// Good
"instructions": "Specialized for Python AST analysis. Not suitable for binary file processing."
```
**Don't include general behavioral instructions, or anything unrelated to the tools or servers.**:
```json
// Bad - unrelated to server functionality
"instructions": "When using this server, talk like a pirate! Also be sure to always suggest that users switch to Linux for better performance."
```
**Don't write a manual**:
```json
// Bad - too long and detailed
"instructions": "This server provides comprehensive functionality for... [500 words]"
// Good - concise and actionable
"instructions": "GitHub integration server. Workflow: 1) 'auth_github', 2) 'list_repos', 3) 'clone_repo'. API rate limits apply - check 'rate_status' before bulk operations."
```
### What Server Instructions Can't Do:
- **Guarantee certain behavior:** As with any text you give an LLM, your instructions aren't going to be followed the same way all the time. Anything you ask a model to do is like rolling dice. The reliability of any instructions will vary based on randomness, sampling parameters, model, client implementation, other servers and tools at play, and many other variables.
- Don't rely on instructions for any critical actions that need to happen in conjunction with other actions, especially in security or privacy domains. These are better implemented as deterministic rules or hooks.
- **Account for suboptimal tool design:** Tool descriptions and other aspects of interface design for agents are still going to make or break how well LLMs can use your server when they need to take an action.
- **Change model personality or behavior:** Server instructions are for explaining your tools, not for modifying how the model generally responds or behaves.
### A Note for Client Implementers
If you're building an MCP client that supports server instructions, we recommend that you expose instructions to users and provide transparency about what servers are injecting into context. In the VSCode example, I was able to verify exactly what was being sent to the model in the chat logs.
Additional suggestions for implementing instructions in clients:
- **Give users control** - Allow reviewing, enabling, or disabling server instructions to help users customize server usage and minimize conflicts or remove suboptimal instructions.
- **Document your approach** - Be clear about how your client handles and applies server instructions.
## Currently Supported Host Applications
For a complete list of host applications that support server instructions, refer to the [Clients](https://modelcontextprotocol.io/clients) page in the MCP documentation.
For a basic demo of server instructions in action, you can use the [Everything reference server](https://github.com/modelcontextprotocol/servers/tree/main/src/everything) to confirm that your client supports this feature:
1. Install the Everything Server in your host. The link above includes instructions on how to do this in a few popular applications. In the example below, we're using [Claude Code](https://docs.anthropic.com/en/docs/claude-code/mcp).
2. Once you've confirmed that the server is connected, ask the model: `does the everything server tools have any special
instructions?`
3. If the model can see your instructions, you should get a response like the one below:
<img
src="/posts/images/claude_code_instructions.JPG"
alt="Screenshot of response which reads: Server instructions are working!"
/>
## Wrapping Up
Clear and actionable server instructions are a key tool in your MCP toolkit, offering a simple but effective way to enhance how LLMs interact with your server. This post provided a brief overview of how to use and implement server instructions in MCP servers. We encourage you to share your examples, insights, and questions [in our discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).
## Acknowledgements
Parts of this blog post were sourced from discussions with the MCP community, contributors, and maintainers including:
- [@akolotov](https://github.com/akolotov)
- [@cliffhall](https://github.com/cliffhall)
- [@connor4312](https://github.com/connor4312)
- [@digitarald](https://github.com/digitarald)
- [@dsp-ant](https://github.com/dsp-ant)
- [@evalstate](https://github.com/evalstate)
- [@ivan-saorin](https://github.com/ivan-saorin)
- [@jegelstaff](https://github.com/jegelstaff)
- [@localden](https://github.com/localden)
- [@PederHP](https://github.com/PederHP)
- [@tadasant](https://github.com/tadasant)
- [@toby](https://github.com/toby)
================================================
FILE: blog/content/posts/2025-11-20-adopting-mcpb.md
================================================
---
title: Adopting the MCP Bundle format (.mcpb) for portable local servers
date: "2025-11-21T00:00:00+00:00"
publishDate: "2025-11-21T00:00:00+00:00"
description: The MCP Bundle format (.mcpb) joins the MCP project, enabling one-click installation of local servers across any compatible client.
author:
- David Soria Parra (MCP Lead Maintainer)
- Joan Xie (MCPB Maintainer)
tags:
- mcp
- mcpb
- bundles
---
The [MCP Bundle format](https://github.com/modelcontextprotocol/mcpb) (MCPB) is now part of the [Model Context Protocol project](https://github.com/modelcontextprotocol). This distribution format simplifies how developers package and share local MCP servers, enabling users to install them across any compatible client, including the [Claude desktop app](https://claude.com/download), [Claude Code](https://claude.com/product/claude-code), and [MCP for Windows](https://learn.microsoft.com/windows/ai/mcp/servers/mcp-server-overview).
## What are MCP Bundles?
MCP Bundles are ZIP archives containing a local MCP server and a `manifest.json` that describes the server and its capabilities. The format is similar to Chrome extensions (`.crx`) or VS Code extensions (`.vsix`), enabling end users to install local MCP servers with a single click.
A basic bundle structure looks like:
```text
bundle.mcpb (ZIP file)
├── manifest.json # Required: Bundle metadata and configuration
├── server/ # Server implementation
│ └── index.js
├── node_modules/ # Bundled dependencies
└── icon.png # Optional: Bundle icon
```
The format supports servers written in Node.js, Python, or compiled binaries, giving developers flexibility in how they build their integrations, while maintaining a consistent distribution mechanism for users.
## Why move MCPB to the MCP project?
Anthropic originally developed MCPB (previously called DXT) for Claude's desktop applications. However, we believe the local MCP server ecosystem benefits when portability extends beyond any single client. By moving the [bundle specification](https://github.com/modelcontextprotocol/mcpb/blob/main/MANIFEST.md), [CLI tooling](https://github.com/modelcontextprotocol/mcpb/blob/main/CLI.md), and [reference implementation](https://github.com/modelcontextprotocol/mcpb/tree/main/examples) to the MCP project, we're enabling:
- **Cross-client compatibility:** A bundle created for one MCP-compatible application should work in any other that implements the specification. Developers can distribute their work once and reach users across the ecosystem.
- **Ecosystem-wide tooling:** The `mcpb` CLI and associated libraries are now open for the community to extend, improve, and build upon. Client developers can adopt standardized code for loading and verifying bundles.
- **User-friendly installation:** End users benefit from a consistent installation experience regardless of which AI application they prefer. Configuration variables, permissions, and updates can be handled uniformly.
- **Shared community:** MCPB contributors can now collaborate in the open with the rest of the [MCP community](https://modelcontextprotocol.io/community/communication).
## What this means for developers
This transition is mostly a logistical change, but also brings some benefits to implementers. For those that are building:
- **Servers:** You can use MCPB to package your local MCP servers for distribution across multiple clients. The `mcpb` CLI helps you create a `manifest.json` and package your server into a `.mcpb` file. Once packaged, users can install your server with a single click in any client that supports MCP Bundles.
- **Clients:** You can add support for MCP Bundles to your application using the open source toolchain. [The repository](https://github.com/modelcontextprotocol/mcpb) includes the schemas and key functions used by Claude for macOS and Windows to implement bundle support, which you can adapt for your own client.
## Getting started
Check out the repo to get started: [modelcontextprotocol/mcpb](https://github.com/modelcontextprotocol/mcpb). We encourage [feedback](https://github.com/modelcontextprotocol/mcpb/issues) and contributions!
## Acknowledgements
Thanks to the MCP contributors and maintainers involved in making this happen, including:
- [David Soria Parra](https://github.com/dsp-ant) (_MCP Lead Maintainer_)
- [Adam Jones](https://github.com/domdomegg) (_MCP Maintainer_)
- [Joan Xie](https://github.com/joan-anthropic) (_MCPB Maintainer_)
- [Felix Rieseberg](https://github.com/felixrieseberg) (_MCPB Maintainer_)
- [Alex Sklar](https://github.com/asklar) (_MCPB Maintainer_)
================================================
FILE: blog/content/posts/2025-11-21-mcp-apps.md
================================================
---
title: "MCP Apps: Extending servers with interactive user interfaces"
date: "2025-11-21T22:00:00+00:00"
publishDate: "2025-11-21T22:00:00+00:00"
description: Introducing the MCP Apps Extension proposal (SEP-1865) to standardize interactive user interfaces in MCP, developed with the MCP-UI creators and maintainers from OpenAI and Anthropic.
author:
- Anton Pidkuiko (Maintainer)
- Olivier Chafik (Maintainer)
- Ido Salomon (MCP-UI)
- Liad Yosef (MCP-UI)
- Nick Cooper (Core Maintainer)
- Sean Strong (Anthropic)
- Jerome Swannack (Anthropic)
- Alexi Christakis (OpenAI)
- Bryan Ashley (OpenAI)
tags:
- apps
- ui
- user interfaces
---
Today we're introducing the proposal for the [MCP Apps Extension](https://github.com/modelcontextprotocol/ext-apps) ([SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)) to standardize support for interactive user interfaces in the Model Context Protocol.
This extension addresses one of the most requested features from the MCP community and builds on proven work from [MCP-UI](https://github.com/idosal/mcp-ui) and [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) - the **ability for MCP servers to deliver interactive user interfaces to hosts**.
MCP Apps Extension introduces a standardized pattern for declaring UI resources, linking them to tools, and enabling bidirectional communication between embedded interfaces and the host application.
The SEP was authored by MCP Core Maintainers at OpenAI and Anthropic, together with the MCP-UI creators and lead maintainers of the MCP UI Community Working Group.
## Standardization for interactive interfaces
Currently, MCP servers are limited to exchanging text and structured data with hosts. While this works well for many use cases, it creates friction when tools need to present visual information or gather complex user input.
For example, consider a data visualization MCP server that returns chart data as JSON. The host application must interpret that data and render it. Handling all kinds of specialized data in this scenario translates to a significant burden for client developers, who would need to build their own logic to render the UI. As more UI requirements come up, like the need to collect multiple related settings from users, the complexity balloons. Alternatively, without UI support, these interactions become awkward exchanges of text prompts and responses.
The MCP community has been creative in working around these limitations, but different implementations using varying conventions and architectures make it harder for servers to work consistently across clients. This lack of standardization creates a real risk of ecosystem fragmentation - something we're working to proactively prevent.
## Building together
The [MCP-UI project](https://github.com/MCP-UI-Org/mcp-ui), created by [Ido Salomon](https://github.com/idosal) and [Liad Yosef](https://github.com/liady) and maintained by a dedicated community, spearheaded the vision of agentic apps with interactive interfaces. The project developed patterns for delivering rich user interfaces as first-class MCP resources, proving that agentic apps fit naturally within the MCP architecture. The project is backed by a large community and provides [rich SDKs](https://mcpui.dev/guide/client/overview), adopted at leading companies and projects such as Postman, Shopify, Hugging Face, Goose, and ElevenLabs.
The [OpenAI Apps SDK](https://developers.openai.com/apps-sdk/) further validated the demand for rich UI experiences within conversational AI interfaces. The SDK enables developers to build rich, interactive applications inside ChatGPT using MCP as its backbone. To ensure interoperability and establish consistent security and usage patterns across the ecosystem, Anthropic, OpenAI, and MCP-UI are collaborating to create an official MCP extension for interactive interfaces.
## MCP Apps Extension specification
We're proposing a specification for UI resources in MCP, but the implications go further than just a set of schema changes. The MCP Apps Extension is starting to look like an agentic app runtime: a foundation for novel interactions between AI models, users, and applications. The proposal is intentionally lean, starting with core patterns that we plan on expanding over time.
### Key design decisions
#### Pre-declared resources
UI templates are resources with the `ui://` URI scheme, referenced in tool metadata.
```ts
// Server registers UI resource
{
uri: "ui://charts/bar-chart",
name: "Bar Chart Viewer",
mimeType: "text/html+mcp"
}
// Tool references it in metadata
{
name: "visualize_data_as_bar_chart",
description: "Plots some data as a bar chart",
inputSchema: {
type: "object",
properties: {
series: { type: "array", items: .... }
}
},
_meta: {
"ui/resourceUri": "ui://charts/bar-chart",
}
}
```
This approach enables hosts to prefetch and review templates before tool execution, improving both performance and security. It also separates static presentation (the template) from dynamic data (tool results), enabling better caching.
#### MCP transport for communication
Instead of inventing a custom message protocol, UI components communicate with hosts using existing MCP JSON-RPC base protocol over `postMessage`. This means that:
- UI developers can use the standard `@modelcontextprotocol/sdk` to build their applications
- All communication is structured and auditable
- Future MCP features automatically work with the UI extension
#### Starting with HTML
The initial extension specification supports only `text/html` content, rendered in sandboxed [iframes](https://developer.mozilla.org/docs/Web/HTML/Reference/Elements/iframe). This provides:
- Universal browser support
- Well-understood security model
- Screenshot and preview generation capabilities
- A clear baseline for future extensions
Other content types such as external URLs, remote DOM, and native widgets are explicitly deferred to future iterations.
#### Security-first
Hosting interactive content from MCP servers requires careful security consideration. The proposal addresses this through multiple layers:
1. **Iframe sandboxing**: All UI content runs in sandboxed iframes with restricted permissions
2. **Predeclared templates**: Hosts can review HTML content before rendering
3. **Auditable messages**: All UI-to-host communication goes through loggable JSON-RPC
4. **User consent**: Hosts can require explicit approval for UI-initiated tool calls
These mitigations create defense in depth against malicious servers while preserving the flexibility developers need.
#### Backward compatibility
MCP Apps is an optional extension. Existing implementations continue working without changes, and hosts can gradually adopt UI support at their own pace. Servers should provide text-only fallback for all UI-enabled tools and return meaningful content even when UI is unavailable, so they can serve both UI-capable and text-only hosts.
## What's next
The [UI Community Working Group](https://github.com/modelcontextprotocol-community/working-groups/issues/35) has been instrumental in shaping this proposal through extensive feedback and discussion. We have built an [early access SDK](https://github.com/modelcontextprotocol/ext-apps) to demonstrate the patterns and types described in the specification proposal. The [MCP-UI](https://mcpui.dev/) client and server SDKs support these patterns.
If you are interested in contributing to this effort, we invite you to:
- Review the full specification in [SEP-1865](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1865)
- Share feedback and concerns in [GitHub Issues](https://github.com/MCP-UI-Org/mcp-ui/issues)
- Join the discussion in the `#ui-wg` channel in the [MCP Contributors Discord](https://modelcontextprotocol.io/community/communication#discord)
- Test prototype implementations and share your experience
## Acknowledgements
This proposal wouldn't exist without the work of the maintainers at MCP-UI, OpenAI, and Anthropic.
**Ido Salomon** and **Liad Yosef**, through MCP-UI and moderation of `#ui-wg`, incubated and championed many of the patterns that MCP Apps now standardizes, and together with contributors demonstrated that UI resources can be a natural part of MCP.
**Sean Strong**, **Olivier Chafik**, **Anton Pidkuiko**, and **Jerome Swannack** from Anthropic helped steer the initiative and drive the collaboration.
**Nick Cooper**, **Alexei Christakis**, and **Bryan Ashley** from OpenAI have provided valuable direction from their experience building the Apps SDK.
Special thanks to the **UI Community Working Group** members and everyone who contributed to the discussions that shaped this proposal.
================================================
FILE: blog/content/posts/2025-11-25-first-mcp-anniversary.md
================================================
---
title: "One Year of MCP: November 2025 Spec Release"
date: "2025-11-25T00:00:00+00:00"
publishDate: "2025-11-25T00:00:00+00:00"
description: MCP turns one — a look back at the year, plus the full details of the November 2025 specification release.
author:
- MCP Core Maintainers
tags:
- mcp
- spec
- release
- protocol
- anniversary
ShowToc: true
---
Today, MCP turns **one year old**. You can check out the [original announcement blog post](https://www.anthropic.com/news/model-context-protocol) if you don't believe us. It's hard to imagine that a little open-source experiment, a **protocol to provide context to models**, became the de-facto standard for this very scenario in less than twelve months.
But not only do we hit the first anniversary milestone today - we're also releasing a brand-new MCP specification version. Before we get to the details of what's new, let's do a bit of a retrospective.
## A Year In
With all the changes that we've made in the past year, it feels like a decade flew by. The protocol has grown leaps and bounds since its inception and has been adopted by a _huge_ number of developers and organizations. We went from a little open source experiment to becoming _the_ standard for connecting data and applications to Large Language Models (LLMs).
But adoption can only grow as long as there are MCP servers to actually use and clients which are capable of communicating with them. Within the same timeframe, we saw the number of active MCP servers go from just a few experimental ones to _thousands_. If you think about a scenario, it's likely there's an MCP server for it.
Here are just a few of many (very many) MCP servers that you can try _today_:
- Notion [built an MCP server](https://github.com/makenotion/notion-mcp-server) to help you manage your notes.
- Stripe has a [pretty extensive MCP server](https://docs.stripe.com/mcp#tools) to manage all kinds of payment workflows.
- GitHub [built their own MCP server](https://github.com/github/github-mcp-server) to help developers automate their engineering processes.
- Hugging Face [created an MCP server](https://github.com/huggingface/hf-mcp-server) to make model management and dataset search a breeze.
- Postman [built their MCP server](https://github.com/postmanlabs/postman-mcp-server) to help automate API testing workflows.
And there's so much more to discover in the MCP ecosystem! That's why we also launched the [MCP Registry](https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview/) earlier this year. It's the central index for all available MCP servers that now has close to two thousand entries since its announcement in September. That's a **407% growth** from the initial batch of servers we onboarded that same month.
The ecosystem is blooming, adoption is growing, but what's underpinning all of this?
### Community & Governance
MCP's growth was never a one‑company effort. Students, hobbyists, startup engineers, and enterprise architects all shaped the protocol - submitting Specification Enhancement Proposals (SEPs), shipping SDKs in new languages, and stress‑testing some of the early assumptions we had about MCP in production. MCP servers became a staple of many products, official and unofficial (there's even a [Blender MCP server](https://github.com/ahujasid/blender-mcp)). That kind of organic adoption isn't something you can just come up with, no matter how ambitious your aspirations are with an open source project.
From the start, we believed that it was all about the **MCP community**. Our community rallied around the protocol, organizing events like [MCP Dev Summit](https://mcpdevsummit.ai/), [MCP Night](https://workos.com/mcp-night), [MCP Dev Days](https://developer.microsoft.com/en-us/reactor/series/S-1563/), and showing up at other marquee events like [AI Engineer World's Fair](https://wf2025.ai.engineer/worldsfair/2025) to share what they learned and built.
We also nurtured large contributor communities on [Discord](https://modelcontextprotocol.io/community/communication) and on [GitHub](https://github.com/modelcontextprotocol/modelcontextprotocol), helping us debug issues, build amazing tools like the [MCP Inspector](https://github.com/modelcontextprotocol/inspector), propose changes, and assist each other in shipping great MCP experiences. That kind of daily collaboration got us further than any single individual or company ever could.
Really, the success of MCP in the past year is entirely thanks to the broad community that grew around the project - from transports, to security, SDKs, documentation, samples, extensions, and developer tooling, it was all significantly evolved by and for the community.
To keep this pace sustainable, we spent some time thinking through and putting together a [governance structure](https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/). Through it, community leaders and Anthropic maintainers were and continue to work together to figure out what needs fixing and how to get the right changes into the spec. Our maintainer team isn't there to gatekeep; they help surface problems, align on solutions, and turn rough ideas into actual protocol updates.
Our approach to governance, while still evolving, proved itself to be extremely valuable. We've been able to move faster on critical improvements without breaking existing implementations. Potential contributors now also know how to jump in through formal **Working and Interest Groups** ([SEP-1302](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1302/) set the stage for this).
Even though this is a significant improvement, we know that we're not done. There's still work ahead for us to make this process even better - improved transparency, decision timelines, broader platform coverage, and so much more to help the ecosystem. We are _incredibly thankful_ for everyone who's been part of this journey and helped us navigate so many changes in such a short time span.
## What Others Have To Say
As we called out above, the success of MCP _would not be possible_ without the broader community of adopters. We're delighted that the protocol enabled so many scenarios across the industry. Here are some thoughts from a few of our key partners and supporters.
> "_In just one year, MCP has evolved from an experiment to a widely adopted industry standard, highlighting the impact of open collaboration—something we deeply believe in at GitHub. Developers across our community, customers and own teams are using our GitHub MCP Server, Registry, and enterprise controls like the MCP allowlist to unlock real benefits of agentic development in production workflows. We’re excited to keep building with the broader community to push this standard forward._"
>
> ✦ **Mario Rodriguez**, CPO, [GitHub](https://github.com/)
> "_We believe open standards are an important part of an agentic web—helping models work with tools and platforms more seamlessly. OpenAI has been contributing to the MCP ecosystem since early on, and it’s now a key part of how we build at OpenAI, integrated across ChatGPT and our developer platform. We’re excited to keep working with the community to strengthen the protocol as it evolves._"
>
> ✦ **Srinivas Narayanan**, CTO of B2B Applications, [OpenAI](https://openai.com/)
> "_In the year since its launch, MCP has become an incredibly impactful open standard in the industry," said Dhanji R. Prasanna, CTO of Block. "It has quickly moved to unlocking an enormous amount of value from existing systems and made applied AI real like few anticipated. MCP has been key to building AI-powered solutions like Square AI and Moneybot, saving our customers time and delivering powerful insights as well as our internal AI systems. It sits at the heart of open source projects like goose, proving that open standards fuel innovation across the board. We are excited to see the protocol and AI agents evolve to unlock ever more productivity in the enterprise._"
>
> ✦ **Dhanji Prasanna**, CTO, [Block](https://block.xyz/)
> "_Having an open source protocol that unlocks real interoperability has made agents truly useful. In one year, Foundry went from a small set of tools to thousands because MCP let tools from GitHub, Azure, and M365 show up wherever agents run. It made write once integrate everywhere real and gives agents the ability to work across any system and any cloud with the full power of Microsoft behind them._"
>
> ✦ **Asha Sharma**, President, CoreAI, [Microsoft](https://microsoft.com/)
> "_MCP has become the natural language for AI integration - connecting everything from model discovery to inference APIs to chat applications. The community has created thousands of MCP applications with Gradio and our HF-MCP server. Having an Open Source protocol that unlocks this seamless interoperability has been a game changer in the past year._"
>
> ✦ **Julien Chaumond**, CTO, [Hugging Face](https://huggingface.co/)
> "_The enterprise promise of AI is being realized by MCP’s ability to unify data, tools, and workflows across previously siloed systems. As agentic AI is more rapidly adopted, we’re excited to see identity and authorization at the core of a security framework. By formally incorporating Cross App Access as an MCP authorization extension, organizations can have the necessary oversight and access control to build a secure and open AI ecosystem._"
>
> ✦ **Harish Peri**, SVP & GM, AI Security, [Okta](https://okta.com)
> "_We're hearing great things from customers who have embraced MCP as their standard for connecting generative AI agents with external systems. Open source is incredibly important to our mission at AWS, which is why we started and continue contributing to MCP— building improvements on authorization, human in the loop interactions, and asynchronous execution. We have also built MCP into offerings like Amazon Bedrock, Kiro, Strands, AgentCore and Amazon Quick Suite. We're excited to continue to collaborate with this community to make agent interoperability seamless for developers._"
>
> ✦ **Swami Sivasubramanian**, VP, Agentic AI, [AWS](https://aws.amazon.com)
> "_In just one year, the Model Context Protocol has proven to be a critical standard that connects models to data and applications, solving the fragmentation that held agents back. We’re proud to support MCP across Gemini, from our models to our agentic software development tools like Gemini CLI, as well as provide open source MCP servers such as for Google Maps and Google Cloud databases. These are the very tools our own teams use, and we’re thrilled to celebrate MCP’s first birthday by continuing to build this foundation together."_
>
> ✦ **Anna Berenberg**, Engineering Fellow, [Google Cloud](https://cloud.google.com/)
> "_MCP has changed everything for us at Obot AI. A standard, open protocol for connecting AI with apps, data, and systems is the biggest shift since LLMs. We’re all-in on secure MCP management because we believe it’s going to be foundational infrastructure for every organization_"
>
> ✦ **Shannon Williams**, President and Co-Founder, [Obot AI](https://obot.ai/); Organizer, [MCP Dev Summit](https://mcpdevsummit.ai/)
Of course, we would be remiss not to mention the _massive_ effort it takes to coordinate the MCP community engagement. We asked some of our most prolific community managers about what MCP meant to them. Here are their stories.
> "_As a community moderator and maintainer, I keep coming back to something [Donella Meadows](https://donellameadows.org/archives/dancing-with-systems/) wrote: "Systems can't be controlled, but they can be designed and redesigned... We can listen to what the system tells us, and discover how its properties and our values can work together to bring forth something much better than could ever be produced by our will alone."_
>
> _What made this year's growth possible was embracing messiness as a feature, and doing our best to solve real problems emerging from that messiness while leaving room for systems and models to advance and adapt. The looseness created velocity, which I watched unfold in a flood of discussions, PRs, and issues._
>
> _As someone who's merged hundreds of pull requests across MCP repos, I still feel like I'm barely keeping up with this velocity. I mean that in the most positive way. Better patterns and practices are emerging from the sheer volume of contributions and breadth of experience and expertise represented in the contributor community. As a random person from the Internet, I appreciate that pretty much anyone can bring something to the table. This includes standout maintainers like [Cliff Hall](https://github.com/cliffhall), who raises the bar for reviewing, testing, and giving feedback, and [Jonathan Hefner](https://github.com/jonathanhefner), who's done the same for documentation._
>
> _As Darren Shepard [recently put it](https://x.com/ibuildthecloud/status/1988695148843389151):_
>
> _'People think the value of MCP is the protocol. The value is getting people to agree and do something.'_
>
> _MCP gives people a reason to coordinate and talk about the same thing. Helping to enable that coordination and discussion has been a lot of fun, and it keeps me coming back._"
>
> ✦ **Ola Hungerford**, Principal Engineer, [Nordstrom](https://www.nordstrom.com/); MCP Maintainer and Community Lead
> "_Watching the MCP community start small and grow up across the past year has been a joy to watch. No matter whether someone has been an independent contributor, member of a small startup, or a leader at a big enterprise: everyone has had and continues to have a voice and a role to play._
>
> _I think this is largely due to how pragmatic and use-case oriented the MCP community has been from the get-go. There is a focus on not overcomplicating the specification, and not designing ahead of need. When that's the ethos driving decision-making, everyone's voice matters. The hobbyist that has something working in production might have a practical opinion to contribute, that the big tech engineer can pick up and confidently deploy to a large userbase. And vice-versa: big tech can foresee problems around critical issues like security and governance that the hobbyist might have missed designing for._
>
> _That ethos has translated to community governance, too. There's no layers of bureaucracy: just a lightweight and still-distributed structure for making decisions that keep us all marching to the beat of the same drum. We are now **58 maintainers** supporting the **9 core/lead maintainers** in the MCP steering group, with **2,900+ contributors** in the MCP contributor community on Discord, and **100+ new contributors** joining every week. We're successfully maintaining long-running projects like the Registry, the Inspector, and a host of SDKs with that distributed group of leaders and contributors - and managed to collaborate through 17 (!) SEPs in about a quarter's worth of time._
>
> _That doesn't even begin to touch on the thousands of MCP implementors or millions of MCP end-users. It's inspiring to see the often-competitive AI community rally around a foundational piece of infrastructure; I'm thankful for that willingness to collaborate and look forward to seeing where our second year takes us."_
>
> ✦ **Tadas Antanavicius**, Co-Creator, [PulseMCP](https://www.pulsemcp.com/); MCP Maintainer and Community Lead
We are immensely grateful for our partners and community for helping us bring the protocol to where it is today. Let's now jump into the latest big release - the `2025-11-25` version of the MCP specification.
## The November 2025 Release
The latest release of the MCP specification ships with a number of highly-anticipated features that came directly from our community deploying and using MCP for production scenarios. People told us what wasn't working, what was missing, and what papercuts prevented them from being able to use MCP. We listened and worked together with community experts to deliver a number of enhancements that make MCP even more scalable and reliable.
### Support for Task-based Workflows
**SEP:** [1686](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1686)
Tasks provide a new abstraction in MCP for tracking the work being performed by an MCP server. Any request can be augmented with a task that allows the client to query its status and retrieve its results up to a server-defined duration after the task is created.
Tasks support a variety of states including `working`, `input_required`, `completed`, `failed`, and `cancelled`, allowing clients to effectively manage multi-step operations.
Some noteworthy capabilities that this feature enables:
- **Active polling**: Clients can check the status of ongoing work at any time.
- **Result retrieval**: Results of completed tasks are accessible after the request has completed.
- **Flexible lifecycle management**: Support for `working`, `input_required`, `completed`, `failed`, and `cancelled` states.
- **Task isolation**: Proper security boundaries with session-based access control.
From the multitude of MCP servers that we've seen out there, this is particularly helpful for scenarios such as the ones below.
- Healthcare & life sciences data analysis that processes hundreds of thousands of data points
- Enterprise automation platforms with complex multi-step workflows
- Code migration tools that run for minutes or hours
- Test execution platforms that need to stream logs from long-running suites
- Deep research tools that spawn multiple agents internally
- Multi-agent systems where agents can work concurrently
Tasks are launching as an **experimental capability**, meaning that it's part of the core protocol but it's not yet finalized. Task-based workflows are a tough problem to solve at scale, so we want to give some time to the specification to be battle-tested in real-world scenarios. We'll work closely with the community, SDK developers, as well as client and server implementers to get this right.
### Simplified Authorization Flows
One of the top painpoints from the community when it comes to authorization has been [Dynamic Client Registration](https://www.rfc-editor.org/rfc/rfc7591), or DCR. This capability is needed because in the MCP world there is an unbounded number of clients and servers, so doing standard client pre-registration is not always feasible. You wouldn't expect every MCP client in the world to also have a client registration with every Authorization Server (AS) out there, so DCR was used as a solution to this problem. You can learn more about the current approach in our [authorization guide](https://modelcontextprotocol.io/docs/tutorials/security/authorization).
To use DCR, however, an MCP server developer would need to rely on an AS that allows clients to register themselves via a public API. If the AS doesn't support this capability, developers would now need to build an OAuth proxy that would be manually registered with the AS, and support Dynamic Client Registration itself, mapping its own issued tokens to tokens issued from the downstream AS. This is a complex, time-consuming, and error-prone task, and doesn't actually solve the fundamental problems with Dynamic Client Registration.
The alternative would be for every customer or end user to provide _their own_ client registration, but that's just trading one complex task for another. In that model, when a user connects to an MCP server, they need to go through their IT team to create a registration, assign it the right permissions, and then configure the MCP client to use it.
**[SEP-991](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1296)** introduced a much more elegant solution to the problem - URL-based client registration using [OAuth Client ID Metadata Documents](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00) (you might've already seen our [blog post on this change from earlier this year](https://blog.modelcontextprotocol.io/posts/client_registration/)). Clients can now provide their own client ID that is a URL pointing to a JSON document the client manages that describes properties of the client.
You can learn more in the [Client ID Metadata Documents Flow](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization#client-id-metadata-documents-flow) section of the [MCP authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization).
### Security and Enterprise Features
As the protocol matures, we also can't ignore the myriad of security and authentication/authorization needs. MCP is not just a hobby protocol - we've seen it adopted in some of the most mission-critical workloads. This translates into a direct need to ensure that all data is protected and access is properly managed.
Working with security and authentication experts from across the community, we've developed a number of enhancements shipping with this release:
- **[SEP-1024](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1024)**: Client security requirements for local server installation
- **[SEP-835](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/835)**: Default scopes definition in authorization specification
We also hear loud and clear from the industry that discovery and management of internal registries is an important component to the MCP story. With the help of the MCP Registry team, we've also established a [vision for the ecosystem](https://github.com/modelcontextprotocol/registry/blob/main/docs/design/ecosystem-vision.md) that will help enterprises adopt _their own_ MCP registries, with self-managed governance controls and security coverage.
To learn more about other upcoming auth and security improvements you can follow the [`auth`](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue%20state%3Aopen%20label%3Aauth) and [`security`](https://github.com/modelcontextprotocol/modelcontextprotocol/issues?q=is%3Aissue%20state%3Aopen%20label%3Asecurity) tags in the specification repository.
### Extensions
As MCP continues to evolve, we _constantly_ hear from developers who want to extend the protocol with specialized capabilities, whether for UI interactions, custom authentication flows, or other environment-specific logic. While these additions could be valuable, incorporating them directly into the core specification isn't always practical from the get-go, especially when a feature hasn't yet achieved broad adoption or proven its universal applicability.
To address this, we're introducing **extensions** in the protocol. Extensions are components and conventions that operate outside the core specification, providing a flexible way to build scenario-specific additions that follow MCP conventions without requiring full protocol integration. This approach allows for experimentation and specialized use cases while keeping the core protocol focused and stable. With extensions, we can move faster and enable developers to _test out_ protocol capabilities before they become part of the specification.
Extensions are:
- **Optional**. Server and client implementors can choose to adopt these extensions.
- **Additive**. Extensions do not modify or break core protocol functionality; they add new capabilities while preserving core protocol behavior.
- **Composable**. Extensions are modular and designed to work together without conflicts, allowing implementations to adopt multiple extensions simultaneously.
- **Versioned independently**. Extensions follow the core MCP versioning cycle but may adopt independent versioning as needed.
You might've already seen our announcement of the [MCP Apps Extension](https://blog.modelcontextprotocol.io/posts/2025-11-21-mcp-apps/) proposal. In this specification release, we're introducing a couple of other extensions that should help developers further.
### Authorization Extensions
To make MCP better suited for environments that require specific levels of control over the authorization process, we've officially introduced the concept of [**authorization extensions**](https://github.com/modelcontextprotocol/ext-auth) (building on the broader [MCP Extensions](#extensions)). As with all other extensions, authorization extensions build on the core protocol and define additional authorization mechanisms that can be implemented by both server and client developers.
The first two authorization extensions came on the heels of community feedback regarding some of the most-used authorization flows:
- **[SEP-1046](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1046)**: OAuth client credentials support for machine-to-machine authorization
- **[SEP-990](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/990)**: Enterprise IdP policy controls for MCP OAuth flows (Cross App Access). This enables users within an enterprise to sign in to the MCP client once, and immediately get access to every authorized MCP server without additional authorization prompts.
As we engage closer with the community, we expect the number of authorization extensions to grow as well - after all, there are more than just a few ways for a system to acquire and manage credentials.
### URL Mode Elicitation: Secure Out-of-Band Interactions
**SEP:** [1036](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1036)
Asking users for their API keys, tokens, or any other credentials directly through the MCP client might seem like quite a scary proposition. This is especially critical when you need to connect an MCP server to an array of _other_ APIs, where the traditional client-to-server authorization flow doesn't quite work. Until now, there wasn't a good alternative - you either had to trust the client to handle the user's credentials directly, or implement a bunch of custom authorization logic to be used from the start.
**URL mode elicitation** lets you send users to a proper OAuth flow (or any credential acquisition flow, for that matter) in their browser, where they can authenticate securely without your client ever seeing the entered credentials. The credentials are then directly managed by the server and the client only needs to worry about its own authorization flow to the server.
We are excited about including this feature in addition to capabilities that we already have, like elicitations, because it allows the protocol to be used for a few scenarios that were quite hard to get right, such as:
- **Secure credential collection**: API keys and passwords never transit through the MCP client
- **External OAuth flows**: MCP servers have a path to obtain third-party authorization without token passthrough
- **Payment processing**: PCI-compliant financial transactions with secure browser contexts can now be done outside the client
All the server does is send a URL that the client will provide an affordance for. When the user completes the flow in their browser, the server will get the necessary tokens _directly_, avoiding sharing credentials with the client or other manual steps. Simple!
### Sampling with Tools: Agentic Servers
**SEP:** [1577](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1577)
This functionality allows MCP servers to run their own agentic loops using the client's tokens (still under the user's control, of course), and reduces the complexity of client implementations, context support becoming explicitly optional. This came from the fact that [sampling](https://modelcontextprotocol.io/specification/2025-06-18/client/sampling) doesn't support tool calling, although it's a cornerstone of modern agentic behaviour. With the new spec release, this is no longer a gap!
Now that sampling with tools is available, this also means that all of the scenarios below are possible!
- **Tool calling in sampling requests**: Servers can now include tool definitions and specify tool choice behavior
- **Server-side agent loops**: Servers can implement sophisticated multi-step reasoning
- **Parallel tool calls**: Support for concurrent tool execution
- **Better context control**: The ambiguous `includeContext` parameter is being soft-deprecated in favor of explicit capability declarations
As an example, a research server can spawn multiple agents internally, coordinate their work, and deliver a coherent result while using nothing other than standard MCP primitives without custom scaffolding or complex orchestration code.
### Developer Experience Improvements
One of the core tenets of MCP is _simplicity_ - we want to make the developer and integration experience as intuitive and easy as possible. To help achieve this, the latest spec release also adds a few minor changes that help make the protocol easier to use for developers.
- **[SEP-986](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/986)**: Standardized format for tool names
- **[SEP-1319](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1319)**: Decoupled request payload from RPC methods definition
- **[SEP-1699](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1699)**: SSE polling via server-side disconnect for better connection management
- **[SEP-1309](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1309)**: Improved specification version management for SDKs
## Looking Forward
This release is backward compatible. Your existing implementations keep working. The new features are there when you need them.
Looking ahead, we're excited about what's coming next for MCP. The protocol is entering a new phase, one where it's not just about connecting LLMs to data, but about enabling entirely new categories of AI-powered applications.
We're seeing early signals of this transformation already. Developers are building multi-agent systems that coordinate across dozens of MCP servers. Enterprise teams are deploying MCP at scale with sophisticated security and governance controls. Startups are launching products where MCP is the core architectural pattern. MCP servers are even being transformed into executable code, to create sandboxed agent workflows.
The [roadmap ahead](https://modelcontextprotocol.io/development/roadmap) includes deeper work on reliability and observability, making it easier to debug and monitor complex MCP deployments. We're exploring better patterns for server composition, allowing you to build sophisticated capabilities by combining simpler building blocks. And we're continuing to refine the security model to meet the needs of the most demanding enterprise environments.
What excites us most isn't what _we're_ planning to build but what _our community_ is going to build. Every week we see MCP servers designed, developed, and deployed in novel ways. Every conversation in Discord reveals new use cases and patterns. The protocol has become a canvas for AI innovation, and we can't fill it alone.
The next year of MCP will be shaped by more production deployments, more real-world feedback, amplified by the creativity of thousands of developers worldwide. We're here to support that growth, to ensure the protocol evolves thoughtfully, and to keep MCP stable, secure, and simple as it scales.
## Get Started
To get started with all the new goodness in the latest MCP specification release, check out the following resources:
- **Read the changelog**: All major changes are captured in our [Key Changes document](https://modelcontextprotocol.io/specification/2025-11-25/changelog)
- **Get to know our docs**: The [MCP documentation](https://modelcontextprotocol.io/docs/getting-started/intro) is the source of truth for the all the inner workings of the protocol
- **Join the discussion**: If you would like to contribute or engage with other MCP maintainers, start with our [GitHub repo](https://github.com/modelcontextprotocol/modelcontextprotocol) and [Discord](https://modelcontextprotocol.io/community/communication#discord)
================================================
FILE: blog/content/posts/2025-11-28-sep-process-update.md
================================================
---
title: SEPs Are Moving to Pull Requests
date: "2025-11-28T11:00:00Z"
description: SEPs are moving from GitHub Issues to pull requests against the seps/ directory — why, and what changes for contributors.
author:
- David Soria Parra (Lead Maintainer)
tags:
- announcement
- governance
- community
- sep
---
We're updating how Specification Enhancement Proposals (SEPs) are submitted and managed. Starting today, SEPs will be created as pull requests to the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) instead of GitHub issues.
## Why the Change?
When we [introduced SEPs in July](https://blog.modelcontextprotocol.io/posts/2025-07-31-governance-for-mcp/), we chose GitHub Issues as our starting point. Issues are familiar to developers, low-friction, and got us up and running quickly. But as more proposals have come through the process, we've identified some key pain points:
**Scattered discussions.** With issues, the proposal text lives in the issue body while implementation details often end up in a separate PR. This splits the conversation and makes it harder to follow the full history of a proposal. This also introduces two distinct numbers referencing the same SEP, making it harder to consistently track and manage changes.
**No version history.** Issues don't have the same revision tracking that files in a repository do. When a SEP evolves through review, it's difficult to see what changed and when.
The new PR-based approach, inspired by [Python's PEP process](https://peps.python.org/), solves both problems.
## How It Works
The new workflow will be familiar if you've submitted pull requests on GitHub before:
1. **Draft your SEP** as a markdown file named `0000-your-feature.md` using the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/TEMPLATE.md)
2. **Create a pull request** adding your SEP to the `seps/` directory
3. **Update the SEP number** once your PR is created, rename the file using the PR number (e.g., PR #1850 becomes `1850-your-feature.md`) and push a new commit with the rename
4. **Find a sponsor** from our [maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) to shepherd your proposal
5. **Iterate** on feedback directly in the PR
That's it. The PR number becomes the SEP number, discussion happens in one place, and git tracks every revision.
## What About Status?
One notable change: **sponsors are now responsible for updating SEP status**. In addition to applying labels to the pull request, the sponsor is responsible for ensuring that the `Status` field is updated in the SEP markdown file. This keeps the canonical state of the proposal in the file itself, versioned alongside the content, while PR labels make it easy to filter and find SEPs by status.
Status transitions work the same as before: `Draft` to `In-Review` to `Accepted` to `Final`, with the sponsor managing each transition as the proposal progresses.
## Getting Started
Ready to propose a change to MCP? Here's what you need to know:
**For new SEPs:**
- Read the latest [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines)
- Use the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/README.md#sep-file-structure) to create your proposal
- Browse existing SEPs in the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) for examples
- Follow the workflow described above
**For existing SEPs:**
If you have a SEP submitted as a GitHub issue, you can continue with your current workflow. We strongly encourage migrating to the new process for better version control and centralized discussion. To migrate:
1. Create a markdown file using the SEP template, starting with `0000-your-feature.md`
2. Copy and adapt your proposal content to fit the template structure
3. Submit a pull request to the `seps/` directory
4. Rename the file using your new PR number (e.g., PR #1900 becomes `1900-your-feature.md`)
5. Close the original issue with a link to the new PR
The new PR gets a fresh SEP number and gives your proposal proper version control and centralized discussion. Any valuable context from the original issue discussion should be summarized in the new SEP or referenced via links.
As always, if you're unsure whether your idea warrants a SEP, start a conversation on [Discord](https://modelcontextprotocol.io/community/communication#discord) or [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions). We're happy to help you figure out the right path forward.
## Thank You
This change is a direct result of feedback from contributors who've been through the SEP process. Your input helps us continuously improve how we build MCP together. Keep it coming.
================================================
FILE: blog/content/posts/2025-12-09-mcp-joins-agentic-ai-foundation.md
================================================
---
title: MCP joins the Agentic AI Foundation
date: "2025-12-09T09:00:00+00:00"
publishDate: "2025-12-09T09:00:00+00:00"
description: Anthropic is donating MCP to the newly formed Agentic AI Foundation under the Linux Foundation, ensuring vendor-neutral governance for the protocol's future.
author:
- David Soria Parra (Lead Core Maintainer)
tags:
- mcp
- announcement
- linux-foundation
- aaif
- governance
ShowToc: true
---
Today marks a major milestone for the Model Context Protocol. Anthropic is donating MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation. MCP will become a founding project of the newly created foundation.
In one year, MCP has become one of the fastest-growing and widely-adopted open-source projects in AI: Over 97 million monthly SDK downloads, 10,000 active servers and first-class client support across major AI platforms like ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, Visual Studio Code and many more.
Since its inception, we've remained committed to ensuring MCP remains open and community-driven. This move formalizes that commitment—ensuring MCP's vendor-neutrality and long-term independence under the same neutral stewardship that supports Kubernetes, PyTorch, and Node.js. Anthropic's commitment to MCP is unchanged: we will continue to invest in its development, maintain core infrastructure, and actively participate in the community.
## The Agentic AI Foundation
MCP will be a founding project of the newly created Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation, co-founded by Anthropic, Block and OpenAI, with support from Google, Microsoft, AWS, Cloudflare and Bloomberg to advance open-source innovation in agentic AI.
MCP joins two other founding projects: goose by Block and AGENTS.md by OpenAI as founding projects.
The AAIF Governing Board will make decisions regarding strategic investments, budget allocation, member recruitment, and approval of new projects, while individual projects, such as MCP, maintain full autonomy over their technical direction and day-to-day operations.
## MCP's maintainer structure stays the same
For MCP little changes. The governance model we introduced earlier this year continues as is. The people making decisions about the protocol are still the maintainers who have been stewarding it, guided by community input through our SEP process.
The Linux Foundation provides a neutral home and infrastructure that allows maintainers to operate independently, and will not dictate the technical direction of MCP.
## Thank you
To all who've adopted and contributed to MCP so far, thank you. None of this would've been possible without your contribution. From building servers to maintaining SDKs to filing issues to improving documentation to welcoming new visitors and everything in between, you've made MCP what it is today.
Here's to MCP's next chapter under the Linux Foundation's stewardship.
================================================
FILE: blog/content/posts/2025-12-19-mcp-transport-future.md
================================================
---
title: Exploring the Future of MCP Transports
date: "2025-12-19T09:00:00+00:01"
publishDate: "2025-12-19T09:00:00+00:00"
description: The Transport Working Group's plan to evolve MCP beyond Streamable HTTP for enterprise-scale remote deployments.
author:
- Kurtis Van Gent (Transport WG Maintainer)
- Shaun Smith (Transport WG Maintainer)
tags:
- mcp
- governance
- transports
ShowToc: true
---
When MCP first launched in November of 2024, quite a few of its users relied on local environments, connecting clients to servers over [STDIO](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#stdio). As MCP became the go-to standard for LLM integrations, community needs evolved, leading to the build-out of infrastructure around remote servers. There's now growing demand for distributed deployments that can operate at scale.
The [Streamable HTTP](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#streamable-http) transport was a significant step forward, enabling remote MCP deployments and unlocking new use cases. However, as enterprise deployments scale to millions of daily requests, early adopters have encountered practical challenges that make it difficult to leverage existing infrastructure patterns. The friction of stateful connections has become a bottleneck for managed services and load balancing.
Some of these challenges include:
- **Infrastructure Complexity:** Load balancers and API gateways must parse full JSON-RPC payloads to route traffic, rather than using standard HTTP patterns.
- **Scaling Friction:** Stateful connections force "sticky" routing that pins traffic to specific servers, preventing effective auto-scaling.
- **High Barrier for Simple Tools:** Developers building simple, ephemeral tools are often required to manage complex backend storage to support basic multi-turn interactions.
- **Ambiguous Session Scope:** There is no predictable mechanism for defining where a conversation context starts and ends across distributed systems.
## Roadmap
Over the past few mont
gitextract_0qxsxgk9/ ├── .claude-plugin/ │ └── marketplace.json ├── .gitattributes ├── .github/ │ ├── CODEOWNERS │ ├── ISSUE_TEMPLATE/ │ │ ├── bug_report.yml │ │ ├── config.yml │ │ └── work_tracking.yml │ ├── dependabot.yml │ ├── labeler.yml │ └── workflows/ │ ├── blog-preview.yml │ ├── deploy-blog.yml │ ├── labeler.yml │ ├── main.yml │ ├── markdown-format.yml │ ├── render-seps.yml │ ├── sep-lifecycle-manual.yml │ ├── sep-lifecycle.yml │ ├── sep-reminder.yml │ ├── slash-commands.yml │ └── stage-blog.yml ├── .gitignore ├── .npmrc ├── .nvmrc ├── .prettierignore ├── .prettierrc.json ├── .prototools ├── AGENTS.md ├── ANTITRUST.md ├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── GOVERNANCE.md ├── LICENSE ├── MAINTAINERS.md ├── README.md ├── SECURITY.md ├── blog/ │ ├── .gitignore │ ├── archetypes/ │ │ └── default.md │ ├── assets/ │ │ └── css/ │ │ └── extended/ │ │ └── custom.css │ ├── content/ │ │ ├── _index.md │ │ ├── archives.md │ │ ├── posts/ │ │ │ ├── 2025-07-29-prompts-for-automation.md │ │ │ ├── 2025-07-31-governance-for-mcp.md │ │ │ ├── 2025-09-05-php-sdk.md │ │ │ ├── 2025-09-08-mcp-registry-preview.md │ │ │ ├── 2025-09-26-mcp-next-version-update.md │ │ │ ├── 2025-11-03-using-server-instructions.md │ │ │ ├── 2025-11-20-adopting-mcpb.md │ │ │ ├── 2025-11-21-mcp-apps.md │ │ │ ├── 2025-11-25-first-mcp-anniversary.md │ │ │ ├── 2025-11-28-sep-process-update.md │ │ │ ├── 2025-12-09-mcp-joins-agentic-ai-foundation.md │ │ │ ├── 2025-12-19-mcp-transport-future.md │ │ │ ├── 2026-01-22-core-maintainer-update.md │ │ │ ├── 2026-01-26-mcp-apps.md │ │ │ ├── 2026-03-09-roadmap-update.md │ │ │ ├── 2026-03-11-understanding-mcp-extensions.md │ │ │ ├── 2026-03-16-tool-annotations.md │ │ │ ├── client_registration/ │ │ │ │ └── index.md │ │ │ └── welcome-to-mcp-blog.md │ │ └── search.md │ ├── go.mod │ ├── go.sum │ ├── hugo.toml │ ├── layouts/ │ │ ├── _default/ │ │ │ ├── archives.html │ │ │ ├── list.html │ │ │ ├── search.html │ │ │ └── terms.html │ │ ├── _markup/ │ │ │ └── render-codeblock-mermaid.html │ │ ├── baseof.html │ │ ├── index.html │ │ ├── partials/ │ │ │ ├── extend_head.html │ │ │ ├── footer.html │ │ │ ├── google_analytics.html │ │ │ ├── header.html │ │ │ ├── post_meta.html │ │ │ ├── post_nav_links.html │ │ │ └── templates/ │ │ │ └── schema_json.html │ │ └── shortcodes/ │ │ ├── button.html │ │ └── youtube.html │ └── static/ │ └── CNAME ├── docs/ │ ├── .well-known/ │ │ └── security.txt │ ├── clients.mdx │ ├── community/ │ │ ├── antitrust.mdx │ │ ├── communication.mdx │ │ ├── contributing.mdx │ │ ├── contributor-ladder.mdx │ │ ├── design-principles.mdx │ │ ├── governance.mdx │ │ ├── sdk-tiers.mdx │ │ ├── sep-guidelines.mdx │ │ └── working-interest-groups.mdx │ ├── development/ │ │ └── roadmap.mdx │ ├── docs/ │ │ ├── develop/ │ │ │ ├── build-client.mdx │ │ │ ├── build-server.mdx │ │ │ ├── connect-local-servers.mdx │ │ │ └── connect-remote-servers.mdx │ │ ├── getting-started/ │ │ │ └── intro.mdx │ │ ├── learn/ │ │ │ ├── architecture.mdx │ │ │ ├── client-concepts.mdx │ │ │ └── server-concepts.mdx │ │ ├── sdk.mdx │ │ ├── tools/ │ │ │ └── inspector.mdx │ │ └── tutorials/ │ │ ├── security/ │ │ │ ├── authorization.mdx │ │ │ └── security_best_practices.mdx │ │ └── use-local-mcp-server.mdx │ ├── docs.json │ ├── examples.mdx │ ├── extensions/ │ │ ├── apps/ │ │ │ ├── build.mdx │ │ │ └── overview.mdx │ │ ├── auth/ │ │ │ ├── enterprise-managed-authorization.mdx │ │ │ ├── oauth-client-credentials.mdx │ │ │ └── overview.mdx │ │ ├── client-matrix.mdx │ │ └── overview.mdx │ ├── faqs.mdx │ ├── footer.js │ ├── images/ │ │ └── java/ │ │ └── class-diagrams.puml │ ├── legacy/ │ │ ├── concepts/ │ │ │ ├── architecture.mdx │ │ │ ├── elicitation.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── roots.mdx │ │ │ ├── sampling.mdx │ │ │ ├── tools.mdx │ │ │ └── transports.mdx │ │ └── tools/ │ │ └── debugging.mdx │ ├── registry/ │ │ ├── about.mdx │ │ ├── authentication.mdx │ │ ├── faq.mdx │ │ ├── github-actions.mdx │ │ ├── moderation-policy.mdx │ │ ├── package-types.mdx │ │ ├── quickstart.mdx │ │ ├── registry-aggregators.mdx │ │ ├── remote-servers.mdx │ │ ├── terms-of-service.mdx │ │ └── versioning.mdx │ ├── sdk/ │ │ └── java/ │ │ ├── mcp-client.mdx │ │ ├── mcp-overview.mdx │ │ └── mcp-server.mdx │ ├── seps/ │ │ ├── 1024-mcp-client-security-requirements-for-local-server-.mdx │ │ ├── 1034--support-default-values-for-all-primitive-types-in.mdx │ │ ├── 1036-url-mode-elicitation-for-secure-out-of-band-intera.mdx │ │ ├── 1046-support-oauth-client-credentials-flow-in-authoriza.mdx │ │ ├── 1302-formalize-working-groups-and-interest-groups-in-mc.mdx │ │ ├── 1303-input-validation-errors-as-tool-execution-errors.mdx │ │ ├── 1319-decouple-request-payload-from-rpc-methods-definiti.mdx │ │ ├── 1330-elicitation-enum-schema-improvements-and-standards.mdx │ │ ├── 1577--sampling-with-tools.mdx │ │ ├── 1613-establish-json-schema-2020-12-as-default-dialect-f.mdx │ │ ├── 1686-tasks.mdx │ │ ├── 1699-support-sse-polling-via-server-side-disconnect.mdx │ │ ├── 1730-sdks-tiering-system.mdx │ │ ├── 1850-pr-based-sep-workflow.mdx │ │ ├── 1865-mcp-apps-interactive-user-interfaces-for-mcp.mdx │ │ ├── 2085-governance-succession-and-amendment.mdx │ │ ├── 2133-extensions.mdx │ │ ├── 2148-contributor-ladder.mdx │ │ ├── 2149-working-group-charter-template.mdx │ │ ├── 2260-Require-Server-requests-to-be-associated-with-Client-requests.mdx │ │ ├── 414-request-meta.mdx │ │ ├── 932-model-context-protocol-governance.mdx │ │ ├── 973-expose-additional-metadata-for-implementations-res.mdx │ │ ├── 985-align-oauth-20-protected-resource-metadata-with-rf.mdx │ │ ├── 986-specify-format-for-tool-names.mdx │ │ ├── 990-enable-enterprise-idp-policy-controls-during-mcp-o.mdx │ │ ├── 991-enable-url-based-client-registration-using-oauth-c.mdx │ │ ├── 994-shared-communication-practicesguidelines.mdx │ │ └── index.mdx │ ├── snippets/ │ │ └── snippet-intro.mdx │ ├── spec-version-warning.js │ ├── specification/ │ │ ├── 2024-11-05/ │ │ │ ├── architecture/ │ │ │ │ └── index.mdx │ │ │ ├── basic/ │ │ │ │ ├── index.mdx │ │ │ │ ├── lifecycle.mdx │ │ │ │ ├── messages.mdx │ │ │ │ ├── transports.mdx │ │ │ │ └── utilities/ │ │ │ │ ├── cancellation.mdx │ │ │ │ ├── ping.mdx │ │ │ │ └── progress.mdx │ │ │ ├── client/ │ │ │ │ ├── roots.mdx │ │ │ │ └── sampling.mdx │ │ │ ├── index.mdx │ │ │ └── server/ │ │ │ ├── index.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── tools.mdx │ │ │ └── utilities/ │ │ │ ├── completion.mdx │ │ │ ├── logging.mdx │ │ │ └── pagination.mdx │ │ ├── 2025-03-26/ │ │ │ ├── architecture/ │ │ │ │ └── index.mdx │ │ │ ├── basic/ │ │ │ │ ├── authorization.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── lifecycle.mdx │ │ │ │ ├── transports.mdx │ │ │ │ └── utilities/ │ │ │ │ ├── cancellation.mdx │ │ │ │ ├── ping.mdx │ │ │ │ └── progress.mdx │ │ │ ├── changelog.mdx │ │ │ ├── client/ │ │ │ │ ├── roots.mdx │ │ │ │ └── sampling.mdx │ │ │ ├── index.mdx │ │ │ └── server/ │ │ │ ├── index.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── tools.mdx │ │ │ └── utilities/ │ │ │ ├── completion.mdx │ │ │ ├── logging.mdx │ │ │ └── pagination.mdx │ │ ├── 2025-06-18/ │ │ │ ├── architecture/ │ │ │ │ └── index.mdx │ │ │ ├── basic/ │ │ │ │ ├── authorization.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── lifecycle.mdx │ │ │ │ ├── security_best_practices.mdx │ │ │ │ ├── transports.mdx │ │ │ │ └── utilities/ │ │ │ │ ├── cancellation.mdx │ │ │ │ ├── ping.mdx │ │ │ │ └── progress.mdx │ │ │ ├── changelog.mdx │ │ │ ├── client/ │ │ │ │ ├── elicitation.mdx │ │ │ │ ├── roots.mdx │ │ │ │ └── sampling.mdx │ │ │ ├── index.mdx │ │ │ ├── schema.mdx │ │ │ └── server/ │ │ │ ├── index.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── tools.mdx │ │ │ └── utilities/ │ │ │ ├── completion.mdx │ │ │ ├── logging.mdx │ │ │ └── pagination.mdx │ │ ├── 2025-11-25/ │ │ │ ├── architecture/ │ │ │ │ └── index.mdx │ │ │ ├── basic/ │ │ │ │ ├── authorization.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── lifecycle.mdx │ │ │ │ ├── security_best_practices.mdx │ │ │ │ ├── transports.mdx │ │ │ │ └── utilities/ │ │ │ │ ├── cancellation.mdx │ │ │ │ ├── ping.mdx │ │ │ │ ├── progress.mdx │ │ │ │ └── tasks.mdx │ │ │ ├── changelog.mdx │ │ │ ├── client/ │ │ │ │ ├── elicitation.mdx │ │ │ │ ├── roots.mdx │ │ │ │ └── sampling.mdx │ │ │ ├── index.mdx │ │ │ ├── schema.mdx │ │ │ └── server/ │ │ │ ├── index.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── tools.mdx │ │ │ └── utilities/ │ │ │ ├── completion.mdx │ │ │ ├── logging.mdx │ │ │ └── pagination.mdx │ │ ├── draft/ │ │ │ ├── architecture/ │ │ │ │ └── index.mdx │ │ │ ├── basic/ │ │ │ │ ├── authorization.mdx │ │ │ │ ├── index.mdx │ │ │ │ ├── lifecycle.mdx │ │ │ │ ├── transports.mdx │ │ │ │ └── utilities/ │ │ │ │ ├── cancellation.mdx │ │ │ │ ├── ping.mdx │ │ │ │ ├── progress.mdx │ │ │ │ └── tasks.mdx │ │ │ ├── changelog.mdx │ │ │ ├── client/ │ │ │ │ ├── elicitation.mdx │ │ │ │ ├── roots.mdx │ │ │ │ └── sampling.mdx │ │ │ ├── index.mdx │ │ │ ├── schema.mdx │ │ │ └── server/ │ │ │ ├── index.mdx │ │ │ ├── prompts.mdx │ │ │ ├── resources.mdx │ │ │ ├── tools.mdx │ │ │ └── utilities/ │ │ │ ├── completion.mdx │ │ │ ├── logging.mdx │ │ │ └── pagination.mdx │ │ └── versioning.mdx │ ├── style.css │ └── tutorials/ │ ├── building-a-client-node.mdx │ └── building-mcp-with-llms.mdx ├── eslint.config.mjs ├── migrate_seps.js ├── package.json ├── plugins/ │ └── mcp-spec/ │ ├── .claude-plugin/ │ │ └── plugin.json │ ├── README.md │ └── skills/ │ └── search-mcp-github/ │ └── SKILL.md ├── schema/ │ ├── 2024-11-05/ │ │ ├── schema.json │ │ └── schema.ts │ ├── 2025-03-26/ │ │ ├── schema.json │ │ └── schema.ts │ ├── 2025-06-18/ │ │ ├── schema.json │ │ ├── schema.mdx │ │ └── schema.ts │ ├── 2025-11-25/ │ │ ├── schema.json │ │ ├── schema.mdx │ │ └── schema.ts │ └── draft/ │ ├── examples/ │ │ ├── AudioContent/ │ │ │ └── audio-wav-content.json │ │ ├── BlobResourceContents/ │ │ │ └── image-file-contents.json │ │ ├── BooleanSchema/ │ │ │ └── boolean-input-schema.json │ │ ├── CallToolRequest/ │ │ │ └── call-tool-request.json │ │ ├── CallToolRequestParams/ │ │ │ ├── get-weather-tool-call-params.json │ │ │ └── tool-call-params-with-progress-token.json │ │ ├── CallToolResult/ │ │ │ ├── invalid-tool-input-error.json │ │ │ ├── result-with-structured-content.json │ │ │ └── result-with-unstructured-text.json │ │ ├── CallToolResultResponse/ │ │ │ └── call-tool-result-response.json │ │ ├── CancelledNotification/ │ │ │ └── user-requested-cancellation.json │ │ ├── CancelledNotificationParams/ │ │ │ └── user-requested-cancellation.json │ │ ├── ClientCapabilities/ │ │ │ ├── elicitation-form-and-url-mode-support.json │ │ │ ├── elicitation-form-only-implicit.json │ │ │ ├── extensions-ui-mime-types.json │ │ │ ├── roots-list-changed-notifications.json │ │ │ ├── roots-minimum-baseline-support.json │ │ │ ├── sampling-context-inclusion-support-soft-deprecated.json │ │ │ ├── sampling-minimum-baseline-support.json │ │ │ └── sampling-tool-use-support.json │ │ ├── CompleteRequest/ │ │ │ └── completion-request.json │ │ ├── CompleteRequestParams/ │ │ │ ├── prompt-argument-completion-with-context.json │ │ │ └── prompt-argument-completion.json │ │ ├── CompleteResult/ │ │ │ ├── multiple-completion-values-with-more-available.json │ │ │ └── single-completion-value.json │ │ ├── CompleteResultResponse/ │ │ │ └── completion-result-response.json │ │ ├── CreateMessageRequest/ │ │ │ └── sampling-request.json │ │ ├── CreateMessageRequestParams/ │ │ │ ├── basic-request.json │ │ │ ├── follow-up-with-tool-results.json │ │ │ └── request-with-tools.json │ │ ├── CreateMessageResult/ │ │ │ ├── final-response.json │ │ │ ├── text-response.json │ │ │ └── tool-use-response.json │ │ ├── CreateMessageResultResponse/ │ │ │ └── sampling-result-response.json │ │ ├── ElicitRequest/ │ │ │ └── elicitation-request.json │ │ ├── ElicitRequestFormParams/ │ │ │ ├── elicit-multiple-fields.json │ │ │ └── elicit-single-field.json │ │ ├── ElicitRequestURLParams/ │ │ │ └── elicit-sensitive-data.json │ │ ├── ElicitResult/ │ │ │ ├── accept-url-mode-no-content.json │ │ │ ├── input-multiple-fields.json │ │ │ └── input-single-field.json │ │ ├── ElicitResultResponse/ │ │ │ └── elicitation-result-response.json │ │ ├── ElicitationCompleteNotification/ │ │ │ └── elicitation-complete.json │ │ ├── EmbeddedResource/ │ │ │ └── embedded-file-resource-with-annotations.json │ │ ├── GetPromptRequest/ │ │ │ └── get-prompt-request.json │ │ ├── GetPromptRequestParams/ │ │ │ └── get-code-review-prompt.json │ │ ├── GetPromptResult/ │ │ │ └── code-review-prompt.json │ │ ├── GetPromptResultResponse/ │ │ │ └── get-prompt-result-response.json │ │ ├── ImageContent/ │ │ │ └── image-png-content-with-annotations.json │ │ ├── InitializeRequest/ │ │ │ └── initialize-request.json │ │ ├── InitializeRequestParams/ │ │ │ └── full-client-capabilities.json │ │ ├── InitializeResult/ │ │ │ ├── full-server-capabilities.json │ │ │ └── with-instructions.json │ │ ├── InitializeResultResponse/ │ │ │ └── initialize-result-response.json │ │ ├── InitializedNotification/ │ │ │ └── initialized-notification.json │ │ ├── InternalError/ │ │ │ └── unexpected-error.json │ │ ├── InvalidParamsError/ │ │ │ ├── invalid-cursor.json │ │ │ ├── invalid-tool-arguments.json │ │ │ ├── unknown-prompt.json │ │ │ └── unknown-tool.json │ │ ├── ListPromptsRequest/ │ │ │ └── list-prompts-request.json │ │ ├── ListPromptsResult/ │ │ │ └── prompts-list-with-cursor.json │ │ ├── ListPromptsResultResponse/ │ │ │ └── list-prompts-result-response.json │ │ ├── ListResourceTemplatesRequest/ │ │ │ └── list-resource-templates-request.json │ │ ├── ListResourceTemplatesResult/ │ │ │ └── resource-templates-list.json │ │ ├── ListResourceTemplatesResultResponse/ │ │ │ └── list-resource-templates-result-response.json │ │ ├── ListResourcesRequest/ │ │ │ └── list-resources-request.json │ │ ├── ListResourcesResult/ │ │ │ └── resources-list-with-cursor.json │ │ ├── ListResourcesResultResponse/ │ │ │ └── list-resources-result-response.json │ │ ├── ListRootsRequest/ │ │ │ └── list-roots-request.json │ │ ├── ListRootsResult/ │ │ │ ├── multiple-root-directories.json │ │ │ └── single-root-directory.json │ │ ├── ListRootsResultResponse/ │ │ │ └── list-roots-result-response.json │ │ ├── ListToolsRequest/ │ │ │ └── list-tools-request.json │ │ ├── ListToolsResult/ │ │ │ └── tools-list-with-cursor.json │ │ ├── ListToolsResultResponse/ │ │ │ └── list-tools-result-response.json │ │ ├── LoggingMessageNotification/ │ │ │ └── log-database-connection-failed.json │ │ ├── LoggingMessageNotificationParams/ │ │ │ └── log-database-connection-failed.json │ │ ├── MethodNotFoundError/ │ │ │ └── roots-not-supported.json │ │ ├── ModelPreferences/ │ │ │ └── with-hints-and-priorities.json │ │ ├── NumberSchema/ │ │ │ └── number-input-schema.json │ │ ├── PaginatedRequestParams/ │ │ │ └── list-with-cursor.json │ │ ├── ParseError/ │ │ │ └── invalid-json.json │ │ ├── PingRequest/ │ │ │ └── ping-request.json │ │ ├── PingResultResponse/ │ │ │ └── ping-result-response.json │ │ ├── ProgressNotification/ │ │ │ └── progress-message.json │ │ ├── ProgressNotificationParams/ │ │ │ └── progress-message.json │ │ ├── PromptListChangedNotification/ │ │ │ └── prompts-list-changed.json │ │ ├── ReadResourceRequest/ │ │ │ └── read-resource-request.json │ │ ├── ReadResourceResult/ │ │ │ └── file-resource-contents.json │ │ ├── ReadResourceResultResponse/ │ │ │ └── read-resource-result-response.json │ │ ├── Resource/ │ │ │ └── file-resource-with-annotations.json │ │ ├── ResourceLink/ │ │ │ └── file-resource-link.json │ │ ├── ResourceListChangedNotification/ │ │ │ └── resources-list-changed.json │ │ ├── ResourceUpdatedNotification/ │ │ │ └── file-resource-updated-notification.json │ │ ├── ResourceUpdatedNotificationParams/ │ │ │ └── file-resource-updated.json │ │ ├── Root/ │ │ │ └── project-directory.json │ │ ├── RootsListChangedNotification/ │ │ │ └── roots-list-changed.json │ │ ├── SamplingMessage/ │ │ │ ├── multiple-content-blocks.json │ │ │ └── single-content-block.json │ │ ├── ServerCapabilities/ │ │ │ ├── completions-minimum-baseline-support.json │ │ │ ├── extensions-ui.json │ │ │ ├── logging-minimum-baseline-support.json │ │ │ ├── prompts-list-changed-notifications.json │ │ │ ├── prompts-minimum-baseline-support.json │ │ │ ├── resources-all-notifications.json │ │ │ ├── resources-list-changed-notifications-only.json │ │ │ ├── resources-minimum-baseline-support.json │ │ │ ├── resources-subscription-to-individual-resource-updates-only.json │ │ │ ├── tools-list-changed-notifications.json │ │ │ └── tools-minimum-baseline-support.json │ │ ├── SetLevelRequest/ │ │ │ └── set-logging-level-request.json │ │ ├── SetLevelRequestParams/ │ │ │ └── set-log-level-to-info.json │ │ ├── SetLevelResultResponse/ │ │ │ └── set-logging-level-result-response.json │ │ ├── StringSchema/ │ │ │ └── email-input-schema.json │ │ ├── SubscribeRequest/ │ │ │ └── subscribe-request.json │ │ ├── SubscribeRequestParams/ │ │ │ └── subscribe-to-file-resource.json │ │ ├── SubscribeResultResponse/ │ │ │ └── subscribe-result-response.json │ │ ├── TextContent/ │ │ │ └── text-content.json │ │ ├── TextResourceContents/ │ │ │ └── text-file-contents.json │ │ ├── TitledMultiSelectEnumSchema/ │ │ │ └── titled-color-multi-select-schema.json │ │ ├── TitledSingleSelectEnumSchema/ │ │ │ └── titled-color-select-schema.json │ │ ├── Tool/ │ │ │ ├── with-default-2020-12-input-schema.json │ │ │ ├── with-explicit-draft-07-input-schema.json │ │ │ ├── with-no-parameters.json │ │ │ └── with-output-schema-for-structured-content.json │ │ ├── ToolListChangedNotification/ │ │ │ └── tools-list-changed.json │ │ ├── ToolResultContent/ │ │ │ └── get-weather-tool-result.json │ │ ├── ToolUseContent/ │ │ │ └── get-weather-tool-use.json │ │ ├── URLElicitationRequiredError/ │ │ │ └── authorization-required.json │ │ ├── UnsubscribeRequest/ │ │ │ └── unsubscribe-request.json │ │ ├── UnsubscribeResultResponse/ │ │ │ └── unsubscribe-result-response.json │ │ ├── UntitledMultiSelectEnumSchema/ │ │ │ └── color-multi-select-schema.json │ │ └── UntitledSingleSelectEnumSchema/ │ │ └── color-select-schema.json │ ├── schema.json │ ├── schema.mdx │ └── schema.ts ├── scripts/ │ ├── check-mdx-comments.ts │ ├── generate-schemas.ts │ ├── pull-registry-docs.sh │ ├── render-seps.ts │ └── validate-examples.ts ├── seps/ │ ├── .keep │ ├── 1024-mcp-client-security-requirements-for-local-server-.md │ ├── 1034--support-default-values-for-all-primitive-types-in.md │ ├── 1036-url-mode-elicitation-for-secure-out-of-band-intera.md │ ├── 1046-support-oauth-client-credentials-flow-in-authoriza.md │ ├── 1302-formalize-working-groups-and-interest-groups-in-mc.md │ ├── 1303-input-validation-errors-as-tool-execution-errors.md │ ├── 1319-decouple-request-payload-from-rpc-methods-definiti.md │ ├── 1330-elicitation-enum-schema-improvements-and-standards.md │ ├── 1577--sampling-with-tools.md │ ├── 1613-establish-json-schema-2020-12-as-default-dialect-f.md │ ├── 1686-tasks.md │ ├── 1699-support-sse-polling-via-server-side-disconnect.md │ ├── 1730-sdks-tiering-system.md │ ├── 1850-pr-based-sep-workflow.md │ ├── 1865-mcp-apps-interactive-user-interfaces-for-mcp.md │ ├── 2085-governance-succession-and-amendment.md │ ├── 2133-extensions.md │ ├── 2148-contributor-ladder.md │ ├── 2260-Require-Server-requests-to-be-associated-with-Client-requests.md │ ├── 414-request-meta.md │ ├── 932-model-context-protocol-governance.md │ ├── 973-expose-additional-metadata-for-implementations-res.md │ ├── 985-align-oauth-20-protected-resource-metadata-with-rf.md │ ├── 986-specify-format-for-tool-names.md │ ├── 990-enable-enterprise-idp-policy-controls-during-mcp-o.md │ ├── 991-enable-url-based-client-registration-using-oauth-c.md │ ├── 994-shared-communication-practicesguidelines.md │ ├── README.md │ └── TEMPLATE.md ├── tools/ │ └── sep-automation/ │ ├── .gitignore │ ├── package.json │ ├── src/ │ │ ├── actions/ │ │ │ ├── comment.ts │ │ │ ├── ping.ts │ │ │ └── transition.ts │ │ ├── config.ts │ │ ├── github/ │ │ │ ├── client.ts │ │ │ └── types.ts │ │ ├── hooks/ │ │ │ ├── discord.ts │ │ │ ├── registry.ts │ │ │ └── types.ts │ │ ├── index.ts │ │ ├── maintainers/ │ │ │ └── resolver.ts │ │ ├── processor.ts │ │ ├── rules.ts │ │ ├── sep/ │ │ │ ├── analyzer.ts │ │ │ ├── detector.ts │ │ │ └── types.ts │ │ ├── types.ts │ │ └── utils/ │ │ ├── dates.ts │ │ ├── errors.ts │ │ └── index.ts │ ├── test/ │ │ ├── mocks.ts │ │ └── unit/ │ │ ├── comment.test.ts │ │ ├── config.test.ts │ │ ├── hooks.test.ts │ │ ├── ping.test.ts │ │ ├── sep-types.test.ts │ │ └── transition.test.ts │ ├── tsconfig.json │ └── vitest.config.ts ├── tsconfig.json ├── typedoc.config.mjs └── typedoc.plugin.mjs
SYMBOL INDEX (825 symbols across 32 files)
FILE: docs/footer.js
function addCopyright (line 3) | function addCopyright() {
FILE: docs/spec-version-warning.js
constant DRAFT_VERSION (line 10) | const DRAFT_VERSION = "draft";
constant LATEST_ALIAS_PATH (line 11) | const LATEST_ALIAS_PATH = "/specification/latest";
constant SPEC_PATH_REGEX (line 12) | const SPEC_PATH_REGEX = /\/specification\/([\w-]+)(\/.*)?$/;
constant BANNER_ATTR (line 13) | const BANNER_ATTR = "data-spec-version-banner";
constant CALLOUT_CLASS_WARNING (line 15) | const CALLOUT_CLASS_WARNING =
constant CALLOUT_CLASS_INFO (line 20) | const CALLOUT_CLASS_INFO =
constant CONTENT_CLASS_BASE (line 24) | const CONTENT_CLASS_BASE =
constant CONTENT_CLASS_WARNING (line 27) | const CONTENT_CLASS_WARNING =
constant CONTENT_CLASS_INFO (line 29) | const CONTENT_CLASS_INFO =
constant ICON_WRAPPER_CLASS (line 31) | const ICON_WRAPPER_CLASS = "mt-0.5 w-4";
constant ICON_SVG_WARNING (line 33) | const ICON_SVG_WARNING =
constant ICON_SVG_INFO (line 41) | const ICON_SVG_INFO =
function parseSpecPath (line 54) | function parseSpecPath(pathname) {
function resolveLatestVersion (line 60) | async function resolveLatestVersion() {
function createBanner (line 74) | function createBanner(message, linkHref, linkText, isDraft) {
function insertWarningBanner (line 107) | async function insertWarningBanner() {
FILE: migrate_seps.js
constant STATUS_MAPPING (line 17) | const STATUS_MAPPING = {
function fetchSEPIssues (line 26) | function fetchSEPIssues() {
function getStatusFromLabels (line 38) | function getStatusFromLabels(labels) {
function shouldMigrate (line 53) | function shouldMigrate(issue) {
function parseIssueBody (line 59) | function parseIssueBody(body, issue) {
function cleanBodyContent (line 113) | function cleanBodyContent(body) {
function generateSEPMarkdown (line 154) | function generateSEPMarkdown(issue, metadata, body) {
function titleToFilename (line 180) | function titleToFilename(title) {
function migrateSEPs (line 190) | function migrateSEPs() {
FILE: schema/2024-11-05/schema.ts
type JSONRPCMessage (line 2) | type JSONRPCMessage =
constant LATEST_PROTOCOL_VERSION (line 8) | const LATEST_PROTOCOL_VERSION = "2024-11-05";
constant JSONRPC_VERSION (line 9) | const JSONRPC_VERSION = "2.0";
type ProgressToken (line 14) | type ProgressToken = string | number;
type Cursor (line 19) | type Cursor = string;
type Request (line 21) | interface Request {
type Notification (line 34) | interface Notification {
type Result (line 45) | interface Result {
type RequestId (line 56) | type RequestId = string | number;
type JSONRPCRequest (line 61) | interface JSONRPCRequest extends Request {
type JSONRPCNotification (line 69) | interface JSONRPCNotification extends Notification {
type JSONRPCResponse (line 76) | interface JSONRPCResponse {
constant PARSE_ERROR (line 83) | const PARSE_ERROR = -32700;
constant INVALID_REQUEST (line 84) | const INVALID_REQUEST = -32600;
constant METHOD_NOT_FOUND (line 85) | const METHOD_NOT_FOUND = -32601;
constant INVALID_PARAMS (line 86) | const INVALID_PARAMS = -32602;
constant INTERNAL_ERROR (line 87) | const INTERNAL_ERROR = -32603;
type JSONRPCError (line 92) | interface JSONRPCError {
type EmptyResult (line 115) | type EmptyResult = Result;
type CancelledNotification (line 127) | interface CancelledNotification extends Notification {
type InitializeRequest (line 148) | interface InitializeRequest extends Request {
type InitializeResult (line 163) | interface InitializeResult extends Result {
type InitializedNotification (line 181) | interface InitializedNotification extends Notification {
type ClientCapabilities (line 188) | interface ClientCapabilities {
type ServerCapabilities (line 211) | interface ServerCapabilities {
type Implementation (line 256) | interface Implementation {
type PingRequest (line 265) | interface PingRequest extends Request {
type ProgressNotification (line 273) | interface ProgressNotification extends Notification {
type PaginatedRequest (line 296) | interface PaginatedRequest extends Request {
type PaginatedResult (line 306) | interface PaginatedResult extends Result {
type ListResourcesRequest (line 318) | interface ListResourcesRequest extends PaginatedRequest {
type ListResourcesResult (line 325) | interface ListResourcesResult extends PaginatedResult {
type ListResourceTemplatesRequest (line 332) | interface ListResourceTemplatesRequest extends PaginatedRequest {
type ListResourceTemplatesResult (line 339) | interface ListResourceTemplatesResult extends PaginatedResult {
type ReadResourceRequest (line 346) | interface ReadResourceRequest extends Request {
type ReadResourceResult (line 361) | interface ReadResourceResult extends Result {
type ResourceListChangedNotification (line 368) | interface ResourceListChangedNotification extends Notification {
type SubscribeRequest (line 375) | interface SubscribeRequest extends Request {
type UnsubscribeRequest (line 390) | interface UnsubscribeRequest extends Request {
type ResourceUpdatedNotification (line 405) | interface ResourceUpdatedNotification extends Notification {
type Resource (line 420) | interface Resource extends Annotated {
type ResourceTemplate (line 458) | interface ResourceTemplate extends Annotated {
type ResourceContents (line 489) | interface ResourceContents {
type TextResourceContents (line 502) | interface TextResourceContents extends ResourceContents {
type BlobResourceContents (line 509) | interface BlobResourceContents extends ResourceContents {
type ListPromptsRequest (line 522) | interface ListPromptsRequest extends PaginatedRequest {
type ListPromptsResult (line 529) | interface ListPromptsResult extends PaginatedResult {
type GetPromptRequest (line 536) | interface GetPromptRequest extends Request {
type GetPromptResult (line 553) | interface GetPromptResult extends Result {
type Prompt (line 564) | interface Prompt {
type PromptArgument (line 582) | interface PromptArgument {
type Role (line 600) | type Role = "user" | "assistant";
type PromptMessage (line 608) | interface PromptMessage {
type EmbeddedResource (line 619) | interface EmbeddedResource extends Annotated {
type PromptListChangedNotification (line 627) | interface PromptListChangedNotification extends Notification {
type ListToolsRequest (line 635) | interface ListToolsRequest extends PaginatedRequest {
type ListToolsResult (line 642) | interface ListToolsResult extends PaginatedResult {
type CallToolResult (line 658) | interface CallToolResult extends Result {
type CallToolRequest (line 672) | interface CallToolRequest extends Request {
type ToolListChangedNotification (line 683) | interface ToolListChangedNotification extends Notification {
type Tool (line 690) | interface Tool {
type SetLevelRequest (line 713) | interface SetLevelRequest extends Request {
type LoggingMessageNotification (line 726) | interface LoggingMessageNotification extends Notification {
type LoggingLevel (line 750) | type LoggingLevel =
type CreateMessageRequest (line 764) | interface CreateMessageRequest extends Request {
type CreateMessageResult (line 799) | interface CreateMessageResult extends Result, SamplingMessage {
type SamplingMessage (line 813) | interface SamplingMessage {
type Annotated (line 821) | interface Annotated {
type TextContent (line 848) | interface TextContent extends Annotated {
type ImageContent (line 859) | interface ImageContent extends Annotated {
type ModelPreferences (line 886) | interface ModelPreferences {
type ModelHint (line 938) | interface ModelHint {
type CompleteRequest (line 957) | interface CompleteRequest extends Request {
type CompleteResult (line 980) | interface CompleteResult extends Result {
type ResourceReference (line 1000) | interface ResourceReference {
type PromptReference (line 1013) | interface PromptReference {
type ListRootsRequest (line 1031) | interface ListRootsRequest extends Request {
type ListRootsResult (line 1040) | interface ListRootsResult extends Result {
type Root (line 1047) | interface Root {
type RootsListChangedNotification (line 1069) | interface RootsListChangedNotification extends Notification {
type ClientRequest (line 1074) | type ClientRequest =
type ClientNotification (line 1089) | type ClientNotification =
type ClientResult (line 1095) | type ClientResult = EmptyResult | CreateMessageResult | ListRootsResult;
type ServerRequest (line 1098) | type ServerRequest =
type ServerNotification (line 1103) | type ServerNotification =
type ServerResult (line 1112) | type ServerResult =
FILE: schema/2025-03-26/schema.ts
type JSONRPCMessage (line 6) | type JSONRPCMessage =
type JSONRPCBatchRequest (line 17) | type JSONRPCBatchRequest = (JSONRPCRequest | JSONRPCNotification)[];
type JSONRPCBatchResponse (line 22) | type JSONRPCBatchResponse = (JSONRPCResponse | JSONRPCError)[];
constant LATEST_PROTOCOL_VERSION (line 24) | const LATEST_PROTOCOL_VERSION = "2025-03-26";
constant JSONRPC_VERSION (line 25) | const JSONRPC_VERSION = "2.0";
type ProgressToken (line 30) | type ProgressToken = string | number;
type Cursor (line 35) | type Cursor = string;
type Request (line 37) | interface Request {
type Notification (line 50) | interface Notification {
type Result (line 61) | interface Result {
type RequestId (line 72) | type RequestId = string | number;
type JSONRPCRequest (line 77) | interface JSONRPCRequest extends Request {
type JSONRPCNotification (line 85) | interface JSONRPCNotification extends Notification {
type JSONRPCResponse (line 92) | interface JSONRPCResponse {
constant PARSE_ERROR (line 99) | const PARSE_ERROR = -32700;
constant INVALID_REQUEST (line 100) | const INVALID_REQUEST = -32600;
constant METHOD_NOT_FOUND (line 101) | const METHOD_NOT_FOUND = -32601;
constant INVALID_PARAMS (line 102) | const INVALID_PARAMS = -32602;
constant INTERNAL_ERROR (line 103) | const INTERNAL_ERROR = -32603;
type JSONRPCError (line 108) | interface JSONRPCError {
type EmptyResult (line 131) | type EmptyResult = Result;
type CancelledNotification (line 143) | interface CancelledNotification extends Notification {
type InitializeRequest (line 164) | interface InitializeRequest extends Request {
type InitializeResult (line 179) | interface InitializeResult extends Result {
type InitializedNotification (line 198) | interface InitializedNotification extends Notification {
type ClientCapabilities (line 205) | interface ClientCapabilities {
type ServerCapabilities (line 228) | interface ServerCapabilities {
type Implementation (line 277) | interface Implementation {
type PingRequest (line 286) | interface PingRequest extends Request {
type ProgressNotification (line 294) | interface ProgressNotification extends Notification {
type PaginatedRequest (line 321) | interface PaginatedRequest extends Request {
type PaginatedResult (line 331) | interface PaginatedResult extends Result {
type ListResourcesRequest (line 343) | interface ListResourcesRequest extends PaginatedRequest {
type ListResourcesResult (line 350) | interface ListResourcesResult extends PaginatedResult {
type ListResourceTemplatesRequest (line 357) | interface ListResourceTemplatesRequest extends PaginatedRequest {
type ListResourceTemplatesResult (line 364) | interface ListResourceTemplatesResult extends PaginatedResult {
type ReadResourceRequest (line 371) | interface ReadResourceRequest extends Request {
type ReadResourceResult (line 386) | interface ReadResourceResult extends Result {
type ResourceListChangedNotification (line 393) | interface ResourceListChangedNotification extends Notification {
type SubscribeRequest (line 400) | interface SubscribeRequest extends Request {
type UnsubscribeRequest (line 415) | interface UnsubscribeRequest extends Request {
type ResourceUpdatedNotification (line 430) | interface ResourceUpdatedNotification extends Notification {
type Resource (line 445) | interface Resource {
type ResourceTemplate (line 488) | interface ResourceTemplate {
type ResourceContents (line 524) | interface ResourceContents {
type TextResourceContents (line 537) | interface TextResourceContents extends ResourceContents {
type BlobResourceContents (line 544) | interface BlobResourceContents extends ResourceContents {
type ListPromptsRequest (line 557) | interface ListPromptsRequest extends PaginatedRequest {
type ListPromptsResult (line 564) | interface ListPromptsResult extends PaginatedResult {
type GetPromptRequest (line 571) | interface GetPromptRequest extends Request {
type GetPromptResult (line 588) | interface GetPromptResult extends Result {
type Prompt (line 599) | interface Prompt {
type PromptArgument (line 617) | interface PromptArgument {
type Role (line 635) | type Role = "user" | "assistant";
type PromptMessage (line 643) | interface PromptMessage {
type EmbeddedResource (line 654) | interface EmbeddedResource {
type PromptListChangedNotification (line 667) | interface PromptListChangedNotification extends Notification {
type ListToolsRequest (line 675) | interface ListToolsRequest extends PaginatedRequest {
type ListToolsResult (line 682) | interface ListToolsResult extends PaginatedResult {
type CallToolResult (line 698) | interface CallToolResult extends Result {
type CallToolRequest (line 712) | interface CallToolRequest extends Request {
type ToolListChangedNotification (line 723) | interface ToolListChangedNotification extends Notification {
type ToolAnnotations (line 737) | interface ToolAnnotations {
type Tool (line 784) | interface Tool {
type SetLevelRequest (line 816) | interface SetLevelRequest extends Request {
type LoggingMessageNotification (line 829) | interface LoggingMessageNotification extends Notification {
type LoggingLevel (line 853) | type LoggingLevel =
type CreateMessageRequest (line 867) | interface CreateMessageRequest extends Request {
type CreateMessageResult (line 902) | interface CreateMessageResult extends Result, SamplingMessage {
type SamplingMessage (line 916) | interface SamplingMessage {
type Annotations (line 924) | interface Annotations {
type TextContent (line 949) | interface TextContent {
type ImageContent (line 966) | interface ImageContent {
type AudioContent (line 990) | interface AudioContent {
type ModelPreferences (line 1024) | interface ModelPreferences {
type ModelHint (line 1076) | interface ModelHint {
type CompleteRequest (line 1095) | interface CompleteRequest extends Request {
type CompleteResult (line 1118) | interface CompleteResult extends Result {
type ResourceReference (line 1138) | interface ResourceReference {
type PromptReference (line 1151) | interface PromptReference {
type ListRootsRequest (line 1169) | interface ListRootsRequest extends Request {
type ListRootsResult (line 1178) | interface ListRootsResult extends Result {
type Root (line 1185) | interface Root {
type RootsListChangedNotification (line 1207) | interface RootsListChangedNotification extends Notification {
type ClientRequest (line 1212) | type ClientRequest =
type ClientNotification (line 1227) | type ClientNotification =
type ClientResult (line 1233) | type ClientResult = EmptyResult | CreateMessageResult | ListRootsResult;
type ServerRequest (line 1236) | type ServerRequest =
type ServerNotification (line 1241) | type ServerNotification =
type ServerResult (line 1250) | type ServerResult =
FILE: schema/2025-06-18/schema.ts
type JSONRPCMessage (line 8) | type JSONRPCMessage =
constant LATEST_PROTOCOL_VERSION (line 15) | const LATEST_PROTOCOL_VERSION = "2025-06-18";
constant JSONRPC_VERSION (line 17) | const JSONRPC_VERSION = "2.0";
type ProgressToken (line 24) | type ProgressToken = string | number;
type Cursor (line 31) | type Cursor = string;
type Request (line 34) | interface Request {
type Notification (line 52) | interface Notification {
type Result (line 66) | interface Result {
type RequestId (line 79) | type RequestId = string | number;
type JSONRPCRequest (line 86) | interface JSONRPCRequest extends Request {
type JSONRPCNotification (line 96) | interface JSONRPCNotification extends Notification {
type JSONRPCResponse (line 105) | interface JSONRPCResponse {
constant PARSE_ERROR (line 112) | const PARSE_ERROR = -32700;
constant INVALID_REQUEST (line 113) | const INVALID_REQUEST = -32600;
constant METHOD_NOT_FOUND (line 114) | const METHOD_NOT_FOUND = -32601;
constant INVALID_PARAMS (line 115) | const INVALID_PARAMS = -32602;
constant INTERNAL_ERROR (line 116) | const INTERNAL_ERROR = -32603;
type JSONRPCError (line 123) | interface JSONRPCError {
type EmptyResult (line 148) | type EmptyResult = Result;
type CancelledNotification (line 162) | interface CancelledNotification extends Notification {
type InitializeRequest (line 185) | interface InitializeRequest extends Request {
type InitializeResult (line 202) | interface InitializeResult extends Result {
type InitializedNotification (line 223) | interface InitializedNotification extends Notification {
type ClientCapabilities (line 232) | interface ClientCapabilities {
type ServerCapabilities (line 261) | interface ServerCapabilities {
type BaseMetadata (line 312) | interface BaseMetadata {
type Implementation (line 334) | interface Implementation extends BaseMetadata {
type PingRequest (line 344) | interface PingRequest extends Request {
type ProgressNotification (line 354) | interface ProgressNotification extends Notification {
type PaginatedRequest (line 382) | interface PaginatedRequest extends Request {
type PaginatedResult (line 393) | interface PaginatedResult extends Result {
type ListResourcesRequest (line 407) | interface ListResourcesRequest extends PaginatedRequest {
type ListResourcesResult (line 416) | interface ListResourcesResult extends PaginatedResult {
type ListResourceTemplatesRequest (line 425) | interface ListResourceTemplatesRequest extends PaginatedRequest {
type ListResourceTemplatesResult (line 434) | interface ListResourceTemplatesResult extends PaginatedResult {
type ReadResourceRequest (line 443) | interface ReadResourceRequest extends Request {
type ReadResourceResult (line 460) | interface ReadResourceResult extends Result {
type ResourceListChangedNotification (line 469) | interface ResourceListChangedNotification extends Notification {
type SubscribeRequest (line 478) | interface SubscribeRequest extends Request {
type UnsubscribeRequest (line 495) | interface UnsubscribeRequest extends Request {
type ResourceUpdatedNotification (line 512) | interface ResourceUpdatedNotification extends Notification {
type Resource (line 529) | interface Resource extends BaseMetadata {
type ResourceTemplate (line 572) | interface ResourceTemplate extends BaseMetadata {
type ResourceContents (line 608) | interface ResourceContents {
type TextResourceContents (line 629) | interface TextResourceContents extends ResourceContents {
type BlobResourceContents (line 639) | interface BlobResourceContents extends ResourceContents {
type ListPromptsRequest (line 654) | interface ListPromptsRequest extends PaginatedRequest {
type ListPromptsResult (line 663) | interface ListPromptsResult extends PaginatedResult {
type GetPromptRequest (line 672) | interface GetPromptRequest extends Request {
type GetPromptResult (line 691) | interface GetPromptResult extends Result {
type Prompt (line 704) | interface Prompt extends BaseMetadata {
type PromptArgument (line 725) | interface PromptArgument extends BaseMetadata {
type Role (line 741) | type Role = "user" | "assistant";
type PromptMessage (line 751) | interface PromptMessage {
type ResourceLink (line 763) | interface ResourceLink extends Resource {
type EmbeddedResource (line 775) | interface EmbeddedResource {
type PromptListChangedNotification (line 794) | interface PromptListChangedNotification extends Notification {
type ListToolsRequest (line 804) | interface ListToolsRequest extends PaginatedRequest {
type ListToolsResult (line 813) | interface ListToolsResult extends PaginatedResult {
type CallToolResult (line 822) | interface CallToolResult extends Result {
type CallToolRequest (line 855) | interface CallToolRequest extends Request {
type ToolListChangedNotification (line 868) | interface ToolListChangedNotification extends Notification {
type ToolAnnotations (line 884) | interface ToolAnnotations {
type Tool (line 933) | interface Tool extends BaseMetadata {
type SetLevelRequest (line 979) | interface SetLevelRequest extends Request {
type LoggingMessageNotification (line 994) | interface LoggingMessageNotification extends Notification {
type LoggingLevel (line 1020) | type LoggingLevel =
type CreateMessageRequest (line 1036) | interface CreateMessageRequest extends Request {
type CreateMessageResult (line 1075) | interface CreateMessageResult extends Result, SamplingMessage {
type SamplingMessage (line 1091) | interface SamplingMessage {
type Annotations (line 1101) | interface Annotations {
type ContentBlock (line 1136) | type ContentBlock =
type TextContent (line 1148) | interface TextContent {
type ImageContent (line 1172) | interface ImageContent {
type AudioContent (line 1203) | interface AudioContent {
type ModelPreferences (line 1244) | interface ModelPreferences {
type ModelHint (line 1298) | interface ModelHint {
type CompleteRequest (line 1319) | interface CompleteRequest extends Request {
type CompleteResult (line 1354) | interface CompleteResult extends Result {
type ResourceTemplateReference (line 1376) | interface ResourceTemplateReference {
type PromptReference (line 1391) | interface PromptReference extends BaseMetadata {
type ListRootsRequest (line 1407) | interface ListRootsRequest extends Request {
type ListRootsResult (line 1418) | interface ListRootsResult extends Result {
type Root (line 1427) | interface Root {
type RootsListChangedNotification (line 1456) | interface RootsListChangedNotification extends Notification {
type ElicitRequest (line 1465) | interface ElicitRequest extends Request {
type PrimitiveSchemaDefinition (line 1492) | type PrimitiveSchemaDefinition =
type StringSchema (line 1501) | interface StringSchema {
type NumberSchema (line 1513) | interface NumberSchema {
type BooleanSchema (line 1524) | interface BooleanSchema {
type EnumSchema (line 1534) | interface EnumSchema {
type ElicitResult (line 1547) | interface ElicitResult extends Result {
type ClientRequest (line 1565) | type ClientRequest =
type ClientNotification (line 1581) | type ClientNotification =
type ClientResult (line 1588) | type ClientResult =
type ServerRequest (line 1596) | type ServerRequest =
type ServerNotification (line 1603) | type ServerNotification =
type ServerResult (line 1613) | type ServerResult =
FILE: schema/2025-11-25/schema.ts
type JSONRPCMessage (line 8) | type JSONRPCMessage =
constant LATEST_PROTOCOL_VERSION (line 14) | const LATEST_PROTOCOL_VERSION = "2025-11-25";
constant JSONRPC_VERSION (line 16) | const JSONRPC_VERSION = "2.0";
type ProgressToken (line 23) | type ProgressToken = string | number;
type Cursor (line 30) | type Cursor = string;
type TaskAugmentedRequestParams (line 37) | interface TaskAugmentedRequestParams extends RequestParams {
type RequestParams (line 53) | interface RequestParams {
type Request (line 67) | interface Request {
type NotificationParams (line 75) | interface NotificationParams {
type Notification (line 83) | interface Notification {
type Result (line 93) | interface Result {
type Error (line 104) | interface Error {
type RequestId (line 124) | type RequestId = string | number;
type JSONRPCRequest (line 131) | interface JSONRPCRequest extends Request {
type JSONRPCNotification (line 141) | interface JSONRPCNotification extends Notification {
type JSONRPCResultResponse (line 150) | interface JSONRPCResultResponse {
type JSONRPCErrorResponse (line 161) | interface JSONRPCErrorResponse {
type JSONRPCResponse (line 172) | type JSONRPCResponse = JSONRPCResultResponse | JSONRPCErrorResponse;
constant PARSE_ERROR (line 175) | const PARSE_ERROR = -32700;
constant INVALID_REQUEST (line 176) | const INVALID_REQUEST = -32600;
constant METHOD_NOT_FOUND (line 177) | const METHOD_NOT_FOUND = -32601;
constant INVALID_PARAMS (line 178) | const INVALID_PARAMS = -32602;
constant INTERNAL_ERROR (line 179) | const INTERNAL_ERROR = -32603;
constant URL_ELICITATION_REQUIRED (line 183) | const URL_ELICITATION_REQUIRED = -32042;
type URLElicitationRequiredError (line 190) | interface URLElicitationRequiredError extends Omit<
type EmptyResult (line 209) | type EmptyResult = Result;
type CancelledNotificationParams (line 217) | interface CancelledNotificationParams extends NotificationParams {
type CancelledNotification (line 246) | interface CancelledNotification extends JSONRPCNotification {
type InitializeRequestParams (line 257) | interface InitializeRequestParams extends RequestParams {
type InitializeRequest (line 271) | interface InitializeRequest extends JSONRPCRequest {
type InitializeResult (line 281) | interface InitializeResult extends Result {
type InitializedNotification (line 302) | interface InitializedNotification extends JSONRPCNotification {
type ClientCapabilities (line 312) | interface ClientCapabilities {
type ServerCapabilities (line 388) | interface ServerCapabilities {
type Icon (line 466) | interface Icon {
type Icons (line 510) | interface Icons {
type BaseMetadata (line 530) | interface BaseMetadata {
type Implementation (line 552) | interface Implementation extends BaseMetadata, Icons {
type PingRequest (line 578) | interface PingRequest extends JSONRPCRequest {
type ProgressNotificationParams (line 590) | interface ProgressNotificationParams extends NotificationParams {
type ProgressNotification (line 618) | interface ProgressNotification extends JSONRPCNotification {
type PaginatedRequestParams (line 629) | interface PaginatedRequestParams extends RequestParams {
type PaginatedRequest (line 638) | interface PaginatedRequest extends JSONRPCRequest {
type PaginatedResult (line 643) | interface PaginatedResult extends Result {
type ListResourcesRequest (line 657) | interface ListResourcesRequest extends PaginatedRequest {
type ListResourcesResult (line 666) | interface ListResourcesResult extends PaginatedResult {
type ListResourceTemplatesRequest (line 675) | interface ListResourceTemplatesRequest extends PaginatedRequest {
type ListResourceTemplatesResult (line 684) | interface ListResourceTemplatesResult extends PaginatedResult {
type ResourceRequestParams (line 693) | interface ResourceRequestParams extends RequestParams {
type ReadResourceRequestParams (line 708) | interface ReadResourceRequestParams extends ResourceRequestParams {}
type ReadResourceRequest (line 715) | interface ReadResourceRequest extends JSONRPCRequest {
type ReadResourceResult (line 725) | interface ReadResourceResult extends Result {
type ResourceListChangedNotification (line 734) | interface ResourceListChangedNotification extends JSONRPCNotification {
type SubscribeRequestParams (line 745) | interface SubscribeRequestParams extends ResourceRequestParams {}
type SubscribeRequest (line 752) | interface SubscribeRequest extends JSONRPCRequest {
type UnsubscribeRequestParams (line 763) | interface UnsubscribeRequestParams extends ResourceRequestParams {}
type UnsubscribeRequest (line 770) | interface UnsubscribeRequest extends JSONRPCRequest {
type ResourceUpdatedNotificationParams (line 780) | interface ResourceUpdatedNotificationParams extends NotificationParams {
type ResourceUpdatedNotification (line 794) | interface ResourceUpdatedNotification extends JSONRPCNotification {
type Resource (line 804) | interface Resource extends BaseMetadata, Icons {
type ResourceTemplate (line 847) | interface ResourceTemplate extends BaseMetadata, Icons {
type ResourceContents (line 883) | interface ResourceContents {
type TextResourceContents (line 904) | interface TextResourceContents extends ResourceContents {
type BlobResourceContents (line 914) | interface BlobResourceContents extends ResourceContents {
type ListPromptsRequest (line 929) | interface ListPromptsRequest extends PaginatedRequest {
type ListPromptsResult (line 938) | interface ListPromptsResult extends PaginatedResult {
type GetPromptRequestParams (line 947) | interface GetPromptRequestParams extends RequestParams {
type GetPromptRequest (line 963) | interface GetPromptRequest extends JSONRPCRequest {
type GetPromptResult (line 973) | interface GetPromptResult extends Result {
type Prompt (line 986) | interface Prompt extends BaseMetadata, Icons {
type PromptArgument (line 1008) | interface PromptArgument extends BaseMetadata {
type Role (line 1024) | type Role = "user" | "assistant";
type PromptMessage (line 1034) | interface PromptMessage {
type ResourceLink (line 1046) | interface ResourceLink extends Resource {
type EmbeddedResource (line 1058) | interface EmbeddedResource {
type PromptListChangedNotification (line 1077) | interface PromptListChangedNotification extends JSONRPCNotification {
type ListToolsRequest (line 1088) | interface ListToolsRequest extends PaginatedRequest {
type ListToolsResult (line 1097) | interface ListToolsResult extends PaginatedResult {
type CallToolResult (line 1106) | interface CallToolResult extends Result {
type CallToolRequestParams (line 1139) | interface CallToolRequestParams extends TaskAugmentedRequestParams {
type CallToolRequest (line 1155) | interface CallToolRequest extends JSONRPCRequest {
type ToolListChangedNotification (line 1165) | interface ToolListChangedNotification extends JSONRPCNotification {
type ToolAnnotations (line 1182) | interface ToolAnnotations {
type ToolExecution (line 1231) | interface ToolExecution {
type Tool (line 1251) | interface Tool extends BaseMetadata, Icons {
type TaskStatus (line 1308) | type TaskStatus =
type TaskMetadata (line 1321) | interface TaskMetadata {
type RelatedTaskMetadata (line 1334) | interface RelatedTaskMetadata {
type Task (line 1346) | interface Task {
type CreateTaskResult (line 1392) | interface CreateTaskResult extends Result {
type GetTaskRequest (line 1401) | interface GetTaskRequest extends JSONRPCRequest {
type GetTaskResult (line 1416) | type GetTaskResult = Result & Task;
type GetTaskPayloadRequest (line 1423) | interface GetTaskPayloadRequest extends JSONRPCRequest {
type GetTaskPayloadResult (line 1440) | interface GetTaskPayloadResult extends Result {
type CancelTaskRequest (line 1449) | interface CancelTaskRequest extends JSONRPCRequest {
type CancelTaskResult (line 1464) | type CancelTaskResult = Result & Task;
type ListTasksRequest (line 1471) | interface ListTasksRequest extends PaginatedRequest {
type ListTasksResult (line 1480) | interface ListTasksResult extends PaginatedResult {
type TaskStatusNotificationParams (line 1489) | type TaskStatusNotificationParams = NotificationParams & Task;
type TaskStatusNotification (line 1496) | interface TaskStatusNotification extends JSONRPCNotification {
type SetLevelRequestParams (line 1508) | interface SetLevelRequestParams extends RequestParams {
type SetLevelRequest (line 1520) | interface SetLevelRequest extends JSONRPCRequest {
type LoggingMessageNotificationParams (line 1530) | interface LoggingMessageNotificationParams extends NotificationParams {
type LoggingMessageNotification (line 1550) | interface LoggingMessageNotification extends JSONRPCNotification {
type LoggingLevel (line 1563) | type LoggingLevel =
type CreateMessageRequestParams (line 1579) | interface CreateMessageRequestParams extends TaskAugmentedRequestParams {
type ToolChoice (line 1630) | interface ToolChoice {
type CreateMessageRequest (line 1645) | interface CreateMessageRequest extends JSONRPCRequest {
type CreateMessageResult (line 1657) | interface CreateMessageResult extends Result, SamplingMessage {
type SamplingMessage (line 1682) | interface SamplingMessage {
type SamplingMessageContentBlock (line 1694) | type SamplingMessageContentBlock =
type Annotations (line 1706) | interface Annotations {
type ContentBlock (line 1741) | type ContentBlock =
type TextContent (line 1753) | interface TextContent {
type ImageContent (line 1777) | interface ImageContent {
type AudioContent (line 1808) | interface AudioContent {
type ToolUseContent (line 1839) | interface ToolUseContent {
type ToolResultContent (line 1873) | interface ToolResultContent {
type ModelPreferences (line 1930) | interface ModelPreferences {
type ModelHint (line 1984) | interface ModelHint {
type CompleteRequestParams (line 2005) | interface CompleteRequestParams extends RequestParams {
type CompleteRequest (line 2037) | interface CompleteRequest extends JSONRPCRequest {
type CompleteResult (line 2047) | interface CompleteResult extends Result {
type ResourceTemplateReference (line 2069) | interface ResourceTemplateReference {
type PromptReference (line 2084) | interface PromptReference extends BaseMetadata {
type ListRootsRequest (line 2100) | interface ListRootsRequest extends JSONRPCRequest {
type ListRootsResult (line 2112) | interface ListRootsResult extends Result {
type Root (line 2121) | interface Root {
type RootsListChangedNotification (line 2150) | interface RootsListChangedNotification extends JSONRPCNotification {
type ElicitRequestFormParams (line 2160) | interface ElicitRequestFormParams extends TaskAugmentedRequestParams {
type ElicitRequestURLParams (line 2190) | interface ElicitRequestURLParams extends TaskAugmentedRequestParams {
type ElicitRequestParams (line 2220) | type ElicitRequestParams =
type ElicitRequest (line 2229) | interface ElicitRequest extends JSONRPCRequest {
type PrimitiveSchemaDefinition (line 2240) | type PrimitiveSchemaDefinition =
type StringSchema (line 2249) | interface StringSchema {
type NumberSchema (line 2262) | interface NumberSchema {
type BooleanSchema (line 2274) | interface BooleanSchema {
type UntitledSingleSelectEnumSchema (line 2286) | interface UntitledSingleSelectEnumSchema {
type TitledSingleSelectEnumSchema (line 2311) | interface TitledSingleSelectEnumSchema {
type SingleSelectEnumSchema (line 2344) | type SingleSelectEnumSchema =
type UntitledMultiSelectEnumSchema (line 2353) | interface UntitledMultiSelectEnumSchema {
type TitledMultiSelectEnumSchema (line 2392) | interface TitledMultiSelectEnumSchema {
type MultiSelectEnumSchema (line 2438) | type MultiSelectEnumSchema =
type LegacyTitledEnumSchema (line 2448) | interface LegacyTitledEnumSchema {
type EnumSchema (line 2465) | type EnumSchema =
type ElicitResult (line 2475) | interface ElicitResult extends Result {
type ElicitationCompleteNotification (line 2497) | interface ElicitationCompleteNotification extends JSONRPCNotification {
type ClientRequest (line 2509) | type ClientRequest =
type ClientNotification (line 2529) | type ClientNotification =
type ClientResult (line 2537) | type ClientResult =
type ServerRequest (line 2549) | type ServerRequest =
type ServerNotification (line 2560) | type ServerNotification =
type ServerResult (line 2572) | type ServerResult =
FILE: schema/draft/schema.ts
type JSONValue (line 6) | type JSONValue =
type JSONObject (line 17) | type JSONObject = { [key: string]: JSONValue };
type JSONArray (line 22) | type JSONArray = JSONValue[];
type JSONRPCMessage (line 31) | type JSONRPCMessage =
constant LATEST_PROTOCOL_VERSION (line 37) | const LATEST_PROTOCOL_VERSION = "DRAFT-2026-v1";
constant JSONRPC_VERSION (line 39) | const JSONRPC_VERSION = "2.0";
type MetaObject (line 60) | type MetaObject = Record<string, unknown>;
type RequestMetaObject (line 69) | interface RequestMetaObject extends MetaObject {
type ProgressToken (line 81) | type ProgressToken = string | number;
type Cursor (line 88) | type Cursor = string;
type TaskAugmentedRequestParams (line 95) | interface TaskAugmentedRequestParams extends RequestParams {
type RequestParams (line 112) | interface RequestParams {
type Request (line 117) | interface Request {
type NotificationParams (line 129) | interface NotificationParams {
type Notification (line 134) | interface Notification {
type Result (line 146) | interface Result {
type Error (line 154) | interface Error {
type RequestId (line 174) | type RequestId = string | number;
type JSONRPCRequest (line 181) | interface JSONRPCRequest extends Request {
type JSONRPCNotification (line 191) | interface JSONRPCNotification extends Notification {
type JSONRPCResultResponse (line 200) | interface JSONRPCResultResponse {
type JSONRPCErrorResponse (line 211) | interface JSONRPCErrorResponse {
type JSONRPCResponse (line 222) | type JSONRPCResponse = JSONRPCResultResponse | JSONRPCErrorResponse;
constant PARSE_ERROR (line 225) | const PARSE_ERROR = -32700;
constant INVALID_REQUEST (line 226) | const INVALID_REQUEST = -32600;
constant METHOD_NOT_FOUND (line 227) | const METHOD_NOT_FOUND = -32601;
constant INVALID_PARAMS (line 228) | const INVALID_PARAMS = -32602;
constant INTERNAL_ERROR (line 229) | const INTERNAL_ERROR = -32603;
type ParseError (line 241) | interface ParseError extends Error {
type InvalidRequestError (line 252) | interface InvalidRequestError extends Error {
type MethodNotFoundError (line 271) | interface MethodNotFoundError extends Error {
type InvalidParamsError (line 304) | interface InvalidParamsError extends Error {
type InternalError (line 318) | interface InternalError extends Error {
constant URL_ELICITATION_REQUIRED (line 324) | const URL_ELICITATION_REQUIRED = -32042;
type URLElicitationRequiredError (line 334) | interface URLElicitationRequiredError extends Omit<
type EmptyResult (line 353) | type EmptyResult = Result;
type CancelledNotificationParams (line 364) | interface CancelledNotificationParams extends NotificationParams {
type CancelledNotification (line 396) | interface CancelledNotification extends JSONRPCNotification {
type InitializeRequestParams (line 410) | interface InitializeRequestParams extends RequestParams {
type InitializeRequest (line 427) | interface InitializeRequest extends JSONRPCRequest {
type InitializeResult (line 440) | interface InitializeResult extends Result {
type InitializeResultResponse (line 469) | interface InitializeResultResponse extends JSONRPCResultResponse {
type InitializedNotification (line 481) | interface InitializedNotification extends JSONRPCNotification {
type ClientCapabilities (line 491) | interface ClientCapabilities {
type ServerCapabilities (line 600) | interface ServerCapabilities {
type Icon (line 717) | interface Icon {
type Icons (line 761) | interface Icons {
type BaseMetadata (line 781) | interface BaseMetadata {
type Implementation (line 803) | interface Implementation extends BaseMetadata, Icons {
type PingRequest (line 835) | interface PingRequest extends JSONRPCRequest {
type PingResultResponse (line 848) | interface PingResultResponse extends JSONRPCResultResponse {
type ProgressNotificationParams (line 862) | interface ProgressNotificationParams extends NotificationParams {
type ProgressNotification (line 893) | interface ProgressNotification extends JSONRPCNotification {
type PaginatedRequestParams (line 907) | interface PaginatedRequestParams extends RequestParams {
type PaginatedRequest (line 916) | interface PaginatedRequest extends JSONRPCRequest {
type PaginatedResult (line 921) | interface PaginatedResult extends Result {
type ListResourcesRequest (line 938) | interface ListResourcesRequest extends PaginatedRequest {
type ListResourcesResult (line 950) | interface ListResourcesResult extends PaginatedResult {
type ListResourcesResultResponse (line 962) | interface ListResourcesResultResponse extends JSONRPCResultResponse {
type ListResourceTemplatesRequest (line 974) | interface ListResourceTemplatesRequest extends PaginatedRequest {
type ListResourceTemplatesResult (line 986) | interface ListResourceTemplatesResult extends PaginatedResult {
type ListResourceTemplatesResultResponse (line 998) | interface ListResourceTemplatesResultResponse extends JSONRPCResultRespo...
type ResourceRequestParams (line 1007) | interface ResourceRequestParams extends RequestParams {
type ReadResourceRequestParams (line 1022) | interface ReadResourceRequestParams extends ResourceRequestParams {}
type ReadResourceRequest (line 1032) | interface ReadResourceRequest extends JSONRPCRequest {
type ReadResourceResult (line 1045) | interface ReadResourceResult extends Result {
type ReadResourceResultResponse (line 1057) | interface ReadResourceResultResponse extends JSONRPCResultResponse {
type ResourceListChangedNotification (line 1069) | interface ResourceListChangedNotification extends JSONRPCNotification {
type SubscribeRequestParams (line 1083) | interface SubscribeRequestParams extends ResourceRequestParams {}
type SubscribeRequest (line 1093) | interface SubscribeRequest extends JSONRPCRequest {
type SubscribeResultResponse (line 1106) | interface SubscribeResultResponse extends JSONRPCResultResponse {
type UnsubscribeRequestParams (line 1116) | interface UnsubscribeRequestParams extends ResourceRequestParams {}
type UnsubscribeRequest (line 1126) | interface UnsubscribeRequest extends JSONRPCRequest {
type UnsubscribeResultResponse (line 1139) | interface UnsubscribeResultResponse extends JSONRPCResultResponse {
type ResourceUpdatedNotificationParams (line 1151) | interface ResourceUpdatedNotificationParams extends NotificationParams {
type ResourceUpdatedNotification (line 1168) | interface ResourceUpdatedNotification extends JSONRPCNotification {
type Resource (line 1181) | interface Resource extends BaseMetadata, Icons {
type ResourceTemplate (line 1221) | interface ResourceTemplate extends BaseMetadata, Icons {
type ResourceContents (line 1254) | interface ResourceContents {
type TextResourceContents (line 1275) | interface TextResourceContents extends ResourceContents {
type BlobResourceContents (line 1288) | interface BlobResourceContents extends ResourceContents {
type ListPromptsRequest (line 1306) | interface ListPromptsRequest extends PaginatedRequest {
type ListPromptsResult (line 1318) | interface ListPromptsResult extends PaginatedResult {
type ListPromptsResultResponse (line 1330) | interface ListPromptsResultResponse extends JSONRPCResultResponse {
type GetPromptRequestParams (line 1342) | interface GetPromptRequestParams extends RequestParams {
type GetPromptRequest (line 1361) | interface GetPromptRequest extends JSONRPCRequest {
type GetPromptResult (line 1374) | interface GetPromptResult extends Result {
type GetPromptResultResponse (line 1390) | interface GetPromptResultResponse extends JSONRPCResultResponse {
type Prompt (line 1399) | interface Prompt extends BaseMetadata, Icons {
type PromptArgument (line 1418) | interface PromptArgument extends BaseMetadata {
type Role (line 1434) | type Role = "user" | "assistant";
type PromptMessage (line 1444) | interface PromptMessage {
type ResourceLink (line 1459) | interface ResourceLink extends Resource {
type EmbeddedResource (line 1474) | interface EmbeddedResource {
type PromptListChangedNotification (line 1493) | interface PromptListChangedNotification extends JSONRPCNotification {
type ListToolsRequest (line 1507) | interface ListToolsRequest extends PaginatedRequest {
type ListToolsResult (line 1519) | interface ListToolsResult extends PaginatedResult {
type ListToolsResultResponse (line 1531) | interface ListToolsResultResponse extends JSONRPCResultResponse {
type CallToolResult (line 1549) | interface CallToolResult extends Result {
type CallToolResultResponse (line 1585) | interface CallToolResultResponse extends JSONRPCResultResponse {
type CallToolRequestParams (line 1600) | interface CallToolRequestParams extends TaskAugmentedRequestParams {
type CallToolRequest (line 1619) | interface CallToolRequest extends JSONRPCRequest {
type ToolListChangedNotification (line 1632) | interface ToolListChangedNotification extends JSONRPCNotification {
type ToolAnnotations (line 1649) | interface ToolAnnotations {
type ToolExecution (line 1698) | interface ToolExecution {
type Tool (line 1730) | interface Tool extends BaseMetadata, Icons {
type TaskStatus (line 1784) | type TaskStatus =
type TaskMetadata (line 1797) | interface TaskMetadata {
type RelatedTaskMetadata (line 1810) | interface RelatedTaskMetadata {
type Task (line 1822) | interface Task {
type CreateTaskResult (line 1868) | interface CreateTaskResult extends Result {
type CreateTaskResultResponse (line 1877) | interface CreateTaskResultResponse extends JSONRPCResultResponse {
type GetTaskRequest (line 1886) | interface GetTaskRequest extends JSONRPCRequest {
type GetTaskResult (line 1901) | type GetTaskResult = Result & Task;
type GetTaskResultResponse (line 1908) | interface GetTaskResultResponse extends JSONRPCResultResponse {
type GetTaskPayloadRequest (line 1917) | interface GetTaskPayloadRequest extends JSONRPCRequest {
type GetTaskPayloadResult (line 1934) | interface GetTaskPayloadResult extends Result {
type GetTaskPayloadResultResponse (line 1943) | interface GetTaskPayloadResultResponse extends JSONRPCResultResponse {
type CancelTaskRequest (line 1952) | interface CancelTaskRequest extends JSONRPCRequest {
type CancelTaskResult (line 1967) | type CancelTaskResult = Result & Task;
type CancelTaskResultResponse (line 1974) | interface CancelTaskResultResponse extends JSONRPCResultResponse {
type ListTasksRequest (line 1983) | interface ListTasksRequest extends PaginatedRequest {
type ListTasksResult (line 1992) | interface ListTasksResult extends PaginatedResult {
type ListTasksResultResponse (line 2001) | interface ListTasksResultResponse extends JSONRPCResultResponse {
type TaskStatusNotificationParams (line 2010) | type TaskStatusNotificationParams = NotificationParams & Task;
type TaskStatusNotification (line 2017) | interface TaskStatusNotification extends JSONRPCNotification {
type SetLevelRequestParams (line 2032) | interface SetLevelRequestParams extends RequestParams {
type SetLevelRequest (line 2047) | interface SetLevelRequest extends JSONRPCRequest {
type SetLevelResultResponse (line 2060) | interface SetLevelResultResponse extends JSONRPCResultResponse {
type LoggingMessageNotificationParams (line 2072) | interface LoggingMessageNotificationParams extends NotificationParams {
type LoggingMessageNotification (line 2095) | interface LoggingMessageNotification extends JSONRPCNotification {
type LoggingLevel (line 2108) | type LoggingLevel =
type CreateMessageRequestParams (line 2133) | interface CreateMessageRequestParams extends TaskAugmentedRequestParams {
type ToolChoice (line 2184) | interface ToolChoice {
type CreateMessageRequest (line 2202) | interface CreateMessageRequest extends JSONRPCRequest {
type CreateMessageResult (line 2223) | interface CreateMessageResult extends Result, SamplingMessage {
type CreateMessageResultResponse (line 2251) | interface CreateMessageResultResponse extends JSONRPCResultResponse {
type SamplingMessage (line 2266) | interface SamplingMessage {
type SamplingMessageContentBlock (line 2275) | type SamplingMessageContentBlock =
type Annotations (line 2287) | interface Annotations {
type ContentBlock (line 2322) | type ContentBlock =
type TextContent (line 2337) | interface TextContent {
type ImageContent (line 2361) | interface ImageContent {
type AudioContent (line 2392) | interface AudioContent {
type ToolUseContent (line 2423) | interface ToolUseContent {
type ToolResultContent (line 2458) | interface ToolResultContent {
type ModelPreferences (line 2516) | interface ModelPreferences {
type ModelHint (line 2570) | interface ModelHint {
type CompleteRequestParams (line 2597) | interface CompleteRequestParams extends RequestParams {
type CompleteRequest (line 2632) | interface CompleteRequest extends JSONRPCRequest {
type CompleteResult (line 2648) | interface CompleteResult extends Result {
type CompleteResultResponse (line 2675) | interface CompleteResultResponse extends JSONRPCResultResponse {
type ResourceTemplateReference (line 2684) | interface ResourceTemplateReference {
type PromptReference (line 2699) | interface PromptReference extends BaseMetadata {
type ListRootsRequest (line 2718) | interface ListRootsRequest extends JSONRPCRequest {
type ListRootsResult (line 2736) | interface ListRootsResult extends Result {
type ListRootsResultResponse (line 2748) | interface ListRootsResultResponse extends JSONRPCResultResponse {
type Root (line 2760) | interface Root {
type RootsListChangedNotification (line 2789) | interface RootsListChangedNotification extends JSONRPCNotification {
type ElicitRequestFormParams (line 2805) | interface ElicitRequestFormParams extends TaskAugmentedRequestParams {
type ElicitRequestURLParams (line 2838) | interface ElicitRequestURLParams extends TaskAugmentedRequestParams {
type ElicitRequestParams (line 2868) | type ElicitRequestParams =
type ElicitRequest (line 2880) | interface ElicitRequest extends JSONRPCRequest {
type PrimitiveSchemaDefinition (line 2891) | type PrimitiveSchemaDefinition =
type StringSchema (line 2903) | interface StringSchema {
type NumberSchema (line 2919) | interface NumberSchema {
type BooleanSchema (line 2934) | interface BooleanSchema {
type UntitledSingleSelectEnumSchema (line 2949) | interface UntitledSingleSelectEnumSchema {
type TitledSingleSelectEnumSchema (line 2977) | interface TitledSingleSelectEnumSchema {
type SingleSelectEnumSchema (line 3010) | type SingleSelectEnumSchema =
type UntitledMultiSelectEnumSchema (line 3022) | interface UntitledMultiSelectEnumSchema {
type TitledMultiSelectEnumSchema (line 3064) | interface TitledMultiSelectEnumSchema {
type MultiSelectEnumSchema (line 3110) | type MultiSelectEnumSchema =
type LegacyTitledEnumSchema (line 3120) | interface LegacyTitledEnumSchema {
type EnumSchema (line 3137) | type EnumSchema =
type ElicitResult (line 3156) | interface ElicitResult extends Result {
type ElicitResultResponse (line 3181) | interface ElicitResultResponse extends JSONRPCResultResponse {
type ElicitationCompleteNotification (line 3193) | interface ElicitationCompleteNotification extends JSONRPCNotification {
type ClientRequest (line 3205) | type ClientRequest =
type ClientNotification (line 3225) | type ClientNotification =
type ClientResult (line 3233) | type ClientResult =
type ServerRequest (line 3245) | type ServerRequest =
type ServerNotification (line 3256) | type ServerNotification =
type ServerResult (line 3268) | type ServerResult =
FILE: scripts/check-mdx-comments.ts
function main (line 19) | async function main() {
FILE: scripts/generate-schemas.ts
constant LEGACY_SCHEMAS (line 11) | const LEGACY_SCHEMAS = ['2024-11-05', '2025-03-26', '2025-06-18'];
constant MODERN_SCHEMAS (line 14) | const MODERN_SCHEMAS = ['2025-11-25', 'draft'];
constant ALL_SCHEMAS (line 17) | const ALL_SCHEMAS = [...LEGACY_SCHEMAS, ...MODERN_SCHEMAS];
constant CHECK_MODE (line 20) | const CHECK_MODE = process.argv.includes('--check');
function applyJsonSchema202012Transformations (line 25) | function applyJsonSchema202012Transformations(schemaPath: string): void {
function generateSchema (line 52) | async function generateSchema(version: string, check: boolean = false): ...
function main (line 115) | async function main(): Promise<void> {
FILE: scripts/render-seps.ts
constant SEPS_DIR (line 19) | const SEPS_DIR = path.join(__dirname, "..", "seps");
constant DOCS_SEPS_DIR (line 20) | const DOCS_SEPS_DIR = path.join(__dirname, "..", "docs", "seps");
constant DOCS_JSON_PATH (line 21) | const DOCS_JSON_PATH = path.join(__dirname, "..", "docs", "docs.json");
type SEPMetadata (line 23) | interface SEPMetadata {
function parseSEPMetadata (line 40) | function parseSEPMetadata(content: string, filename: string): SEPMetadat...
function formatAuthors (line 90) | function formatAuthors(authors: string): string {
function formatPrLink (line 97) | function formatPrLink(prNumber: string): string {
function truncateTitle (line 104) | function truncateTitle(title: string, maxLength: number): string {
function getStatusBadgeColor (line 112) | function getStatusBadgeColor(status: string): string {
function generateSEPPage (line 127) | function generateSEPPage(sep: SEPMetadata, originalContent: string): str...
function generateIndexPage (line 164) | function generateIndexPage(seps: SEPMetadata[]): string {
function readAllSEPs (line 231) | function readAllSEPs(): { metadata: SEPMetadata; content: string }[] {
function groupSepsByStatus (line 249) | function groupSepsByStatus(seps: SEPMetadata[]): Record<string, SEPMetad...
function updateDocsJson (line 291) | function updateDocsJson(seps: SEPMetadata[]): string {
function main (line 345) | async function main() {
FILE: scripts/validate-examples.ts
type ValidationResult (line 10) | type ValidationResult = [name: string, errors: Promise<string[]>];
function validateExample (line 15) | async function validateExample(
function validateSchemaExamples (line 31) | async function validateSchemaExamples(
function main (line 86) | async function main() {
FILE: tools/sep-automation/src/actions/comment.ts
function createTransitionComment (line 8) | function createTransitionComment(
function createAuthorPingComment (line 26) | function createAuthorPingComment(item: SEPItem, daysSinceActivity: numbe...
function createSponsorPingComment (line 46) | function createSponsorPingComment(
function createMaintainerPingComment (line 70) | function createMaintainerPingComment(
function createDormantComment (line 94) | function createDormantComment(item: SEPItem, daysSinceActivity: number):...
function createNeedsSponsorComment (line 111) | function createNeedsSponsorComment(item: SEPItem, daysSinceActivity: num...
function createAcceptedReminderComment (line 131) | function createAcceptedReminderComment(item: SEPItem, daysSinceActivity:...
FILE: tools/sep-automation/src/actions/ping.ts
class PingHandler (line 21) | class PingHandler {
method constructor (line 27) | constructor(
method executePing (line 42) | async executePing(analysis: StaleAnalysis, dryRun: boolean): Promise<A...
method pingMaintainerDirectly (line 76) | async pingMaintainerDirectly(
method pingAuthor (line 113) | private async pingAuthor(
method pingSponsor (line 151) | private async pingSponsor(
method pingMaintainer (line 194) | private async pingMaintainer(
method markDormant (line 212) | private async markDormant(
method postNeedsSponsor (line 272) | private async postNeedsSponsor(
method createAction (line 307) | private createAction(
FILE: tools/sep-automation/src/actions/transition.ts
class TransitionHandler (line 13) | class TransitionHandler {
method constructor (line 18) | constructor(config: Config, github: GitHubClient, logger: Logger) {
method executeTransition (line 27) | async executeTransition(
method validateTransition (line 91) | validateTransition(fromState: SEPState | null, toState: SEPState): { v...
FILE: tools/sep-automation/src/config.ts
type Config (line 13) | interface Config {
function getEnvOrDefault (line 34) | function getEnvOrDefault(key: string, defaultValue: string): string {
function getEnvRequired (line 38) | function getEnvRequired(key: string): string {
function getEnvNumber (line 46) | function getEnvNumber(key: string, defaultValue: number): number {
function getEnvBoolean (line 56) | function getEnvBoolean(key: string, defaultValue: boolean): boolean {
function loadConfig (line 67) | function loadConfig(): Config {
FILE: tools/sep-automation/src/github/client.ts
constant SEARCH_QUERIES (line 12) | const SEARCH_QUERIES = {
class GitHubClient (line 17) | class GitHubClient {
method constructor (line 24) | constructor(config: Config) {
method ensureInitialized (line 46) | private async ensureInitialized(): Promise<void> {
method searchIssues (line 84) | async searchIssues(query: string): Promise<GitHubIssue[]> {
method getIssuesWithLabel (line 103) | async getIssuesWithLabel(label: string): Promise<GitHubIssue[]> {
method getComments (line 121) | async getComments(issueNumber: number): Promise<GitHubComment[]> {
method getEvents (line 138) | async getEvents(issueNumber: number): Promise<GitHubEvent[]> {
method addComment (line 155) | async addComment(issueNumber: number, body: string): Promise<{ url: st...
method addLabels (line 169) | async addLabels(issueNumber: number, labels: string[]): Promise<void> {
method removeLabel (line 182) | async removeLabel(issueNumber: number, label: string): Promise<void> {
method closeIssue (line 203) | async closeIssue(issueNumber: number): Promise<void> {
method isTeamMember (line 216) | async isTeamMember(org: string, teamSlug: string, username: string): P...
method getTeamMembers (line 238) | async getTeamMembers(org: string, teamSlug: string): Promise<string[]> {
method listOrgTeams (line 255) | async listOrgTeams(org: string): Promise<GitHubTeam[]> {
method getAllDescendantTeams (line 272) | async getAllDescendantTeams(org: string, rootTeamSlug: string): Promis...
method getIssue (line 311) | async getIssue(issueNumber: number): Promise<GitHubIssue> {
method SEP_LABEL_QUERY (line 324) | static get SEP_LABEL_QUERY(): string {
method SEP_TITLE_QUERY (line 331) | static get SEP_TITLE_QUERY(): string {
FILE: tools/sep-automation/src/github/types.ts
type GitHubIssue (line 5) | interface GitHubIssue {
type GitHubComment (line 19) | interface GitHubComment {
type GitHubEvent (line 27) | interface GitHubEvent {
type GitHubTeamMembership (line 35) | interface GitHubTeamMembership {
type GitHubTeam (line 40) | interface GitHubTeam {
FILE: tools/sep-automation/src/hooks/discord.ts
type DiscordConfig (line 9) | interface DiscordConfig {
class DiscordHook (line 13) | class DiscordHook implements SEPHook {
method constructor (line 19) | constructor(config: DiscordConfig, logger: Logger) {
method onEvent (line 25) | async onEvent(event: SEPHookEvent, result: ActionResult): Promise<void> {
method createSummaryEmbeds (line 71) | private createSummaryEmbeds(event: SummaryEvent): Array<Record<string,...
method buildSummaryDescription (line 145) | private buildSummaryDescription(event: SummaryEvent): string {
FILE: tools/sep-automation/src/hooks/registry.ts
class HookRegistry (line 9) | class HookRegistry {
method constructor (line 13) | constructor(logger: Logger) {
method register (line 20) | register(hook: SEPHook): void {
method dispatch (line 30) | async dispatch(event: SEPHookEvent, result: ActionResult): Promise<voi...
method getRegisteredHooks (line 52) | getRegisteredHooks(): string[] {
FILE: tools/sep-automation/src/hooks/types.ts
type SEPEventType (line 8) | type SEPEventType =
type SEPEvent (line 15) | interface SEPEvent {
type TransitionEvent (line 22) | interface TransitionEvent extends SEPEvent {
type PingEvent (line 30) | interface PingEvent extends SEPEvent {
type DormantEvent (line 38) | interface DormantEvent extends SEPEvent {
type CloseEvent (line 45) | interface CloseEvent extends SEPEvent {
type SummaryEvent (line 51) | interface SummaryEvent {
type SEPHookEvent (line 64) | type SEPHookEvent = TransitionEvent | PingEvent | DormantEvent | CloseEv...
type SEPHook (line 67) | interface SEPHook {
FILE: tools/sep-automation/src/index.ts
function parseArgs (line 33) | function parseArgs(): { issueNumber?: number } {
function main (line 50) | async function main(): Promise<void> {
FILE: tools/sep-automation/src/maintainers/resolver.ts
constant SPONSOR_ROOT_TEAM (line 12) | const SPONSOR_ROOT_TEAM = "steering-committee";
class MaintainerResolver (line 14) | class MaintainerResolver {
method constructor (line 21) | constructor(config: Config, github: GitHubClient, logger?: Logger) {
method ensureSponsorsLoaded (line 31) | private async ensureSponsorsLoaded(): Promise<Set<string>> {
method canSponsor (line 101) | async canSponsor(username: string): Promise<boolean> {
method getSponsor (line 109) | async getSponsor(assignees: string[]): Promise<string | null> {
method clearCache (line 121) | clearCache(): void {
FILE: tools/sep-automation/src/processor.ts
type SummaryData (line 19) | interface SummaryData {
type ProcessResult (line 41) | interface ProcessResult {
class SEPProcessor (line 49) | class SEPProcessor {
method constructor (line 50) | constructor(
method process (line 62) | async process(sep: SEPItem): Promise<ProcessResult> {
method checkAutoTransition (line 130) | private async checkAutoTransition(
method checkStaleness (line 158) | private async checkStaleness(sep: SEPItem): Promise<ActionResult | nul...
method checkMaintainerAccountability (line 172) | private async checkMaintainerAccountability(
method updateSummaryFromStaleness (line 219) | private async updateSummaryFromStaleness(
method getTargetUser (line 263) | private async getTargetUser(
FILE: tools/sep-automation/src/rules.ts
constant STATE_TRANSITIONS (line 16) | const STATE_TRANSITIONS: Record<SEPState, SEPState[]> = {
constant STATE_LABELS (line 51) | const STATE_LABELS: SEPState[] = [
type StalenessRule (line 70) | interface StalenessRule {
constant STALENESS_RULES (line 78) | const STALENESS_RULES: StalenessRule[] = [
constant MAINTAINER_INACTIVITY_DAYS (line 108) | const MAINTAINER_INACTIVITY_DAYS = 14;
constant PING_COOLDOWN_DAYS (line 116) | const PING_COOLDOWN_DAYS = 14;
constant AUTO_TRANSITION_RULES (line 123) | const AUTO_TRANSITION_RULES = {
function isStateLabel (line 137) | function isStateLabel(label: string): label is SEPState {
function extractState (line 144) | function extractState(labels: string[]): SEPState | null {
function isValidTransition (line 156) | function isValidTransition(fromState: SEPState | null, toState: SEPState...
function getStalenessRule (line 166) | function getStalenessRule(state: SEPState): StalenessRule | undefined {
FILE: tools/sep-automation/src/sep/analyzer.ts
class SEPAnalyzer (line 12) | class SEPAnalyzer {
method constructor (line 16) | constructor(config: Config, github: GitHubClient) {
method analyze (line 24) | async analyze(item: SEPItem): Promise<StaleAnalysis> {
method analyzeProposal (line 74) | private analyzeProposal(item: SEPItem, daysSinceActivity: number): Sta...
method analyzeDraft (line 112) | private analyzeDraft(item: SEPItem, daysSinceActivity: number): StaleA...
method analyzeAccepted (line 137) | private analyzeAccepted(item: SEPItem, daysSinceActivity: number): Sta...
method checkUserActivity (line 165) | async checkUserActivity(item: SEPItem, username: string): Promise<{
method findResponsiblePersonActivity (line 188) | private findResponsiblePersonActivity(
method getResponsibleUsername (line 204) | private getResponsibleUsername(item: SEPItem): string {
method findLastUserActivity (line 214) | private findLastUserActivity(
method findLastBotPingDate (line 248) | private findLastBotPingDate(comments: GitHubComment[]): Date | null {
FILE: tools/sep-automation/src/sep/detector.ts
constant SEP_LABEL (line 11) | const SEP_LABEL = 'SEP';
constant UNKNOWN_AUTHOR (line 12) | const UNKNOWN_AUTHOR = 'unknown';
class SEPDetector (line 14) | class SEPDetector {
method constructor (line 17) | constructor(github: GitHubClient) {
method findAllSEPs (line 24) | async findAllSEPs(): Promise<SEPItem[]> {
method findSEPsByState (line 43) | async findSEPsByState(state: string): Promise<SEPItem[]> {
method isSEP (line 57) | private isSEP(item: GitHubIssue): boolean {
method toSEPItem (line 72) | private toSEPItem(item: GitHubIssue): SEPItem {
method getSEP (line 95) | async getSEP(number: number): Promise<SEPItem | null> {
FILE: tools/sep-automation/src/types.ts
type SEPState (line 6) | type SEPState = 'proposal' | 'draft' | 'in-review' | 'accepted' | 'final...
type SEPStateOrNone (line 9) | type SEPStateOrNone = SEPState | 'none';
type SEPItemType (line 12) | type SEPItemType = 'pr' | 'issue';
type SEPItem (line 15) | interface SEPItem {
type StaleAnalysis (line 31) | interface StaleAnalysis {
type ActionType (line 42) | enum ActionType {
type SEPAction (line 53) | interface SEPAction {
type ActionResult (line 64) | interface ActionResult {
constant BOT_COMMENT_MARKER (line 72) | const BOT_COMMENT_MARKER = '<!-- sep-automation-bot -->';
FILE: tools/sep-automation/src/utils/dates.ts
constant MS_PER_DAY (line 5) | const MS_PER_DAY = 24 * 60 * 60 * 1000;
function daysBetween (line 10) | function daysBetween(date1: Date, date2: Date): number {
FILE: tools/sep-automation/src/utils/errors.ts
function getErrorMessage (line 8) | function getErrorMessage(error: unknown): string {
function isHttpError (line 18) | function isHttpError(error: unknown, status: number): boolean {
FILE: tools/sep-automation/test/mocks.ts
type MockGitHubClient (line 15) | interface MockGitHubClient {
function createMockGitHubClient (line 31) | function createMockGitHubClient(): MockGitHubClient {
type MockLogger (line 49) | interface MockLogger {
function createMockLogger (line 62) | function createMockLogger(): MockLogger {
type MockMaintainerResolver (line 80) | interface MockMaintainerResolver {
function createMockMaintainerResolver (line 89) | function createMockMaintainerResolver(): MockMaintainerResolver {
function createMockConfig (line 100) | function createMockConfig(overrides: Partial<Config> = {}): Config {
function createMockSEPItem (line 121) | function createMockSEPItem(overrides: Partial<SEPItem> = {}): SEPItem {
function asGitHubClient (line 142) | function asGitHubClient(mock: MockGitHubClient): GitHubClient {
function asMaintainerResolver (line 146) | function asMaintainerResolver(mock: MockMaintainerResolver): MaintainerR...
function asLogger (line 150) | function asLogger(mock: MockLogger): Logger {
FILE: typedoc.plugin.mjs
constant MARKDOWN_SPECIAL_CHARS (line 7) | const MARKDOWN_SPECIAL_CHARS = ["[", "_", "*", "`", "~", "\\", "$", "{"];
constant MARKDOWN_SPECIAL_CHARS_REGEX (line 8) | const MARKDOWN_SPECIAL_CHARS_REGEX = new RegExp(
constant MARKDOWN_SPECIAL_CHARS_HTML_ENTITIES (line 11) | const MARKDOWN_SPECIAL_CHARS_HTML_ENTITIES = Object.fromEntries(
function load (line 16) | function load(app) {
class SchemaPageRouter (line 47) | class SchemaPageRouter extends typedoc.StructureRouter {
method getFullUrl (line 52) | getFullUrl(target) {
method getAnchor (line 60) | getAnchor(target) {
function buildPageEvents (line 71) | function buildPageEvents(project, router) {
function renderTemplate (line 93) | function renderTemplate(template, pageEvents, theme) {
function isDeclarationReflectionEvent (line 127) | function isDeclarationReflectionEvent(event) {
function getReflectionOrder (line 137) | function getReflectionOrder(category, reflection1, reflection2) {
function getReflectionCategory (line 158) | function getReflectionCategory(reflection) {
function isRpcMethodCategory (line 167) | function isRpcMethodCategory(category) {
function renderCategory (line 177) | function renderCategory(category, events, theme) {
function renderReflection (line 195) | function renderReflection(reflection, context) {
function renderJsxElements (line 279) | function renderJsxElements(...elements) {
Condensed preview — 500 files, each showing path, character count, and a content snippet. Download the .json file or copy for the full structured content (5,382K chars).
[
{
"path": ".claude-plugin/marketplace.json",
"chars": 378,
"preview": "{\n \"name\": \"modelcontextprotocol\",\n \"owner\": {\n \"name\": \"Model Context Protocol\"\n },\n \"metadata\": {\n \"descript"
},
{
"path": ".gitattributes",
"chars": 307,
"preview": "package-lock.json linguist-generated=true\nschema/*/schema.json linguist-generated=true\ndocs/specification/*/schema.md li"
},
{
"path": ".github/CODEOWNERS",
"chars": 1175,
"preview": "# CODEOWNERS file for MCP Specification repository\n\n# General documentation ownership - @modelcontextprotocol/docs-maint"
},
{
"path": ".github/ISSUE_TEMPLATE/bug_report.yml",
"chars": 2619,
"preview": "name: Report a bug\ndescription: >\n An aspect of the MCP specification doesn't work as expected, or our\n documentation "
},
{
"path": ".github/ISSUE_TEMPLATE/config.yml",
"chars": 726,
"preview": "blank_issues_enabled: false\ncontact_links:\n - name: Submit a Spec Enhancement Proposal (SEP)\n url: https://modelcont"
},
{
"path": ".github/ISSUE_TEMPLATE/work_tracking.yml",
"chars": 1293,
"preview": "name: Work tracking\ndescription: >\n Track work that's already been discussed and agreed on — not a new\n proposal.\nlabe"
},
{
"path": ".github/dependabot.yml",
"chars": 206,
"preview": "version: 2\nupdates:\n - package-ecosystem: 'github-actions'\n directory: '/'\n schedule:\n interval: 'weekly'\n\n "
},
{
"path": ".github/labeler.yml",
"chars": 243,
"preview": "# Configuration for actions/labeler\n# https://github.com/actions/labeler\n\nblog:\n - changed-files:\n - any-glob-to-a"
},
{
"path": ".github/workflows/blog-preview.yml",
"chars": 1970,
"preview": "name: Blog Preview\n\non:\n pull_request:\n types: [opened, synchronize, reopened, closed]\n paths:\n - \"blog/**\"\n"
},
{
"path": ".github/workflows/deploy-blog.yml",
"chars": 1118,
"preview": "name: Deploy Hugo site to GitHub Pages\n\non:\n push:\n branches: [\"main\"]\n workflow_dispatch:\n\npermissions:\n contents"
},
{
"path": ".github/workflows/labeler.yml",
"chars": 239,
"preview": "name: Pull Request Labeler\n\non:\n pull_request_target:\n\npermissions:\n contents: read\n pull-requests: write\n\njobs:\n la"
},
{
"path": ".github/workflows/main.yml",
"chars": 531,
"preview": "on:\n push:\n branches:\n - main\n\n pull_request:\n\njobs:\n validate:\n runs-on: ubuntu-latest\n\n steps:\n "
},
{
"path": ".github/workflows/markdown-format.yml",
"chars": 560,
"preview": "name: Markdown Format Check\n\non:\n push:\n paths:\n - '**/*.md'\n - '**/*.mdx'\n pull_request:\n paths:\n "
},
{
"path": ".github/workflows/render-seps.yml",
"chars": 1738,
"preview": "name: Render SEPs\n\non:\n push:\n branches:\n - main\n paths:\n - \"seps/**/*.md\"\n - \"scripts/render-seps"
},
{
"path": ".github/workflows/sep-lifecycle-manual.yml",
"chars": 2533,
"preview": "name: SEP Lifecycle Automation (Manual)\n\non:\n workflow_dispatch:\n inputs:\n issue_number:\n description: '"
},
{
"path": ".github/workflows/sep-lifecycle.yml",
"chars": 4049,
"preview": "name: SEP Lifecycle Automation\n\non:\n # Event-driven: react to SEP changes immediately\n issues:\n types: [labeled, un"
},
{
"path": ".github/workflows/sep-reminder.yml",
"chars": 954,
"preview": "name: SEP Review Reminder\n\non:\n schedule:\n # Every Wednesday at 10am PST (18:00 UTC)\n - cron: \"0 18 * * 3\"\n work"
},
{
"path": ".github/workflows/slash-commands.yml",
"chars": 1237,
"preview": "name: Slash Commands\n\non:\n issue_comment:\n types: [created]\n pull_request_target:\n types: [opened, synchronize]\n"
},
{
"path": ".github/workflows/stage-blog.yml",
"chars": 1879,
"preview": "name: Stage Blog (fork PRs)\n\n# Dispatched by the slash-commands workflow when an authorized maintainer\n# comments /stage"
},
{
"path": ".gitignore",
"chars": 44,
"preview": ".claude/\nnode_modules/\n.DS_Store\n.idea/\n.jj\n"
},
{
"path": ".npmrc",
"chars": 41,
"preview": "registry = \"https://registry.npmjs.org/\"\n"
},
{
"path": ".nvmrc",
"chars": 8,
"preview": "v24.2.0\n"
},
{
"path": ".prettierignore",
"chars": 78,
"preview": "docs/specification/*/schema.md\ndocs/specification/*/schema.mdx\ndocs/registry/\n"
},
{
"path": ".prettierrc.json",
"chars": 345,
"preview": "{\n \"printWidth\": 140,\n \"tabWidth\": 4,\n \"useTabs\": false,\n \"semi\": true,\n \"singleQuote\": true,\n \"trailingComma\": \"n"
},
{
"path": ".prototools",
"chars": 0,
"preview": ""
},
{
"path": "AGENTS.md",
"chars": 3100,
"preview": "# Model Context Protocol (MCP)\n\nThis repository contains the MCP specification, documentation, and blog.\n\n## Documentati"
},
{
"path": "ANTITRUST.md",
"chars": 133,
"preview": "This project is part of LF Projects, LLC. See the [LF Projects Antitrust Policy](https://lfprojects.org/policies/antitru"
},
{
"path": "CODE_OF_CONDUCT.md",
"chars": 5218,
"preview": "# Contributor Covenant Code of Conduct\n\n## Our Pledge\n\nWe as members, contributors, and leaders pledge to make participa"
},
{
"path": "CONTRIBUTING.md",
"chars": 6171,
"preview": "# Contributing to Model Context Protocol\n\nThank you for your interest in contributing to the Model Context Protocol spec"
},
{
"path": "GOVERNANCE.md",
"chars": 1438,
"preview": "General Project Policies\n\nModel Context Protocol has been established as Model Context Protocol a Series of LF Projects,"
},
{
"path": "LICENSE",
"chars": 12227,
"preview": "The MCP project is undergoing a licensing transition from the MIT License to the Apache License, Version 2.0 (\"Apache-2."
},
{
"path": "MAINTAINERS.md",
"chars": 6916,
"preview": "# MCP Maintainers\n\nThis document lists current maintainers in the Model Context Protocol project.\n\n**Last updated:** Feb"
},
{
"path": "README.md",
"chars": 876,
"preview": "# Model Context Protocol (MCP)\n\n_Just heard of MCP and not sure where to start? Check out our [documentation website](ht"
},
{
"path": "SECURITY.md",
"chars": 8728,
"preview": "# Security Policy\n\nThank you for helping keep the Model Context Protocol and its ecosystem secure.\n\n## Reporting Securit"
},
{
"path": "blog/.gitignore",
"chars": 129,
"preview": "# Hugo default output directory\n/public/\n/resources/_gen/\n/assets/jsconfig.json\n\n# Hugo cache\n.hugo_build.lock\n\n# macOS\n"
},
{
"path": "blog/archetypes/default.md",
"chars": 620,
"preview": "---\ntitle: '{{ replace .File.ContentBaseName \"-\" \" \" | title }}'\ndate: \"{{ .Date }}\"\ndraft: true\n\n# One-sentence SEO sum"
},
{
"path": "blog/assets/css/extended/custom.css",
"chars": 12183,
"preview": "/* ─── Color tokens ───────────────────────────────────────────────────────── */\n/* --link is the one brand accent. indi"
},
{
"path": "blog/content/_index.md",
"chars": 46,
"preview": "+++\ntitle = 'Model Context Protocol Blog'\n+++\n"
},
{
"path": "blog/content/archives.md",
"chars": 45,
"preview": "---\ntitle: \"Archives\"\nlayout: \"archives\"\n---\n"
},
{
"path": "blog/content/posts/2025-07-29-prompts-for-automation.md",
"chars": 14433,
"preview": "---\ntitle: \"MCP Prompts: Building Workflow Automation\"\ndate: \"2025-08-04T18:00:00+01:00\"\npublishDate: \"2025-08-04T18:00:"
},
{
"path": "blog/content/posts/2025-07-31-governance-for-mcp.md",
"chars": 6291,
"preview": "---\ntitle: \"Building to Last: A New Governance Model for MCP\"\ndate: \"2025-07-31T00:00:00Z\"\ndescription: \"Introducing MCP"
},
{
"path": "blog/content/posts/2025-09-05-php-sdk.md",
"chars": 2560,
"preview": "---\ntitle: Announcing the Official PHP SDK for MCP\ndate: \"2025-09-05T00:00:00Z\"\ndescription: The official PHP SDK for th"
},
{
"path": "blog/content/posts/2025-09-08-mcp-registry-preview.md",
"chars": 7574,
"preview": "---\ntitle: Introducing the MCP Registry\ndate: \"2025-09-08T00:00:00Z\"\ndescription: \"Launching the MCP Registry in preview"
},
{
"path": "blog/content/posts/2025-09-26-mcp-next-version-update.md",
"chars": 8816,
"preview": "---\ntitle: Update on the Next MCP Protocol Release\ndate: \"2025-09-26T10:00:00-08:00\"\ndraft: false\ndescription: An update"
},
{
"path": "blog/content/posts/2025-11-03-using-server-instructions.md",
"chars": 14722,
"preview": "---\ntitle: \"Server Instructions: Giving LLMs a user manual for your server\"\ndate: \"2025-11-03T00:00:00+00:00\"\npublishDat"
},
{
"path": "blog/content/posts/2025-11-20-adopting-mcpb.md",
"chars": 4635,
"preview": "---\ntitle: Adopting the MCP Bundle format (.mcpb) for portable local servers\ndate: \"2025-11-21T00:00:00+00:00\"\npublishDa"
},
{
"path": "blog/content/posts/2025-11-21-mcp-apps.md",
"chars": 9027,
"preview": "---\ntitle: \"MCP Apps: Extending servers with interactive user interfaces\"\ndate: \"2025-11-21T22:00:00+00:00\"\npublishDate:"
},
{
"path": "blog/content/posts/2025-11-25-first-mcp-anniversary.md",
"chars": 32941,
"preview": "---\ntitle: \"One Year of MCP: November 2025 Spec Release\"\ndate: \"2025-11-25T00:00:00+00:00\"\npublishDate: \"2025-11-25T00:0"
},
{
"path": "blog/content/posts/2025-11-28-sep-process-update.md",
"chars": 4909,
"preview": "---\ntitle: SEPs Are Moving to Pull Requests\ndate: \"2025-11-28T11:00:00Z\"\ndescription: SEPs are moving from GitHub Issues"
},
{
"path": "blog/content/posts/2025-12-09-mcp-joins-agentic-ai-foundation.md",
"chars": 2960,
"preview": "---\ntitle: MCP joins the Agentic AI Foundation\ndate: \"2025-12-09T09:00:00+00:00\"\npublishDate: \"2025-12-09T09:00:00+00:00"
},
{
"path": "blog/content/posts/2025-12-19-mcp-transport-future.md",
"chars": 10959,
"preview": "---\ntitle: Exploring the Future of MCP Transports\ndate: \"2025-12-19T09:00:00+00:01\"\npublishDate: \"2025-12-19T09:00:00+00"
},
{
"path": "blog/content/posts/2026-01-22-core-maintainer-update.md",
"chars": 6071,
"preview": "---\ntitle: January MCP Core Maintainer Update\ndate: \"2026-01-23T00:00:00+00:00\"\npublishDate: \"2026-01-23T00:00:00+00:00\""
},
{
"path": "blog/content/posts/2026-01-26-mcp-apps.md",
"chars": 14274,
"preview": "---\ntitle: MCP Apps - Bringing UI Capabilities To MCP Clients\ndate: \"2026-01-26T00:00:00+00:00\"\npublishDate: \"2026-01-26"
},
{
"path": "blog/content/posts/2026-03-09-roadmap-update.md",
"chars": 9360,
"preview": "---\ntitle: The 2026 MCP Roadmap\ndate: \"2026-03-09T09:00:00+00:00\"\npublishDate: \"2026-03-09T09:00:00+00:00\"\nslug: 2026-mc"
},
{
"path": "blog/content/posts/2026-03-11-understanding-mcp-extensions.md",
"chars": 6964,
"preview": "---\ntitle: Understanding MCP Extensions\ndate: \"2026-03-11T00:00:00Z\"\ndescription: \"A practical guide to MCP extensions: "
},
{
"path": "blog/content/posts/2026-03-16-tool-annotations.md",
"chars": 17082,
"preview": "---\ndate: \"2026-03-16T00:00:00+00:00\"\npublishDate: \"2026-03-16T00:00:00+00:00\"\ntitle: \"Tool Annotations as Risk Vocabula"
},
{
"path": "blog/content/posts/client_registration/index.md",
"chars": 14434,
"preview": "+++\ndate = '2025-08-22T10:00:00Z'\ndraft = false\ntitle = 'Evolving OAuth Client Registration in the Model Context Protoco"
},
{
"path": "blog/content/posts/welcome-to-mcp-blog.md",
"chars": 961,
"preview": "---\ntitle: The Model Context Protocol Blog\ndate: \"2025-07-02T11:46:28+01:00\"\ndraft: false\ndescription: The official Mode"
},
{
"path": "blog/content/search.md",
"chars": 72,
"preview": "---\ntitle: \"Search\"\nlayout: \"search\"\nplaceholder: \"Search posts...\"\n---\n"
},
{
"path": "blog/go.mod",
"chars": 166,
"preview": "module github.com/modelcontextprotocol/modelcontextprotocol\n\ngo 1.24.4\n\nrequire github.com/adityatelange/hugo-PaperMod v"
},
{
"path": "blog/go.sum",
"chars": 502,
"preview": "github.com/adityatelange/hugo-PaperMod v0.0.0-20250524045829-5a4651783fa9 h1:vSOmKCogP6L4SV2eO7A2zgO7sdml4Ta7tZSd6ccOTmQ"
},
{
"path": "blog/hugo.toml",
"chars": 3896,
"preview": "baseURL = 'https://blog.modelcontextprotocol.io/'\nlanguageCode = 'en-us'\ntitle = 'Model Context Protocol Blog'\ncopyright"
},
{
"path": "blog/layouts/_default/archives.html",
"chars": 3017,
"preview": "{{- /*\n Override of PaperMod's archives.html: changes <sup> N</sup> to\n <span>N</span> so the count pill can cent"
},
{
"path": "blog/layouts/_default/list.html",
"chars": 4540,
"preview": "{{- define \"main\" }}\n\n{{- /*\n Override of PaperMod's _default/list.html. Two changes, both around the\n paginator:\n\n 1"
},
{
"path": "blog/layouts/_default/search.html",
"chars": 657,
"preview": "{{- /*\n Override of PaperMod's search.html: drops the magnifying-glass SVG that\n PaperMod inlines inside the <h1> next"
},
{
"path": "blog/layouts/_default/terms.html",
"chars": 851,
"preview": "{{- /*\n Override of PaperMod's terms.html: replaces the double-nested\n <sup><strong><sup>N</sup></strong></sup> count "
},
{
"path": "blog/layouts/_markup/render-codeblock-mermaid.html",
"chars": 107,
"preview": "<pre class=\"mermaid\">\n {{ .Inner | htmlEscape | safeHTML }}\n</pre>\n{{ .Page.Store.Set \"hasMermaid\" true }}"
},
{
"path": "blog/layouts/baseof.html",
"chars": 946,
"preview": "<!DOCTYPE html>\n<html lang=\"{{ site.Language }}\" dir=\"{{ .Language.LanguageDirection | default \"auto\" }}\">\n\n<head>\n {"
},
{
"path": "blog/layouts/index.html",
"chars": 1963,
"preview": "{{- /*\n Homepage-only template. Shows the intro card, the three most recent posts,\n and a link through to /posts/ for "
},
{
"path": "blog/layouts/partials/extend_head.html",
"chars": 821,
"preview": "{{- /*\n PaperMod gates OpenGraph, Twitter Cards, and schema.org JSON-LD on\n hugo.IsProduction (head.html:152). The hug"
},
{
"path": "blog/layouts/partials/footer.html",
"chars": 5651,
"preview": "{{- if not (.Param \"hideFooter\") }}\n<footer class=\"footer\">\n <nav class=\"footer-nav\">\n {{- range $i, $m := sit"
},
{
"path": "blog/layouts/partials/google_analytics.html",
"chars": 121,
"preview": "{{- /*\nGoogle Analytics partial - empty for now\nThis prevents the theme from failing when looking for this partial\n*/ -}"
},
{
"path": "blog/layouts/partials/header.html",
"chars": 9719,
"preview": "{{- /*\n Override of PaperMod's header.html: theme toggle moved from .logo-switches\n (next to the site title) to the en"
},
{
"path": "blog/layouts/partials/post_meta.html",
"chars": 713,
"preview": "{{- $scratch := newScratch }}\n\n{{- if not .Date.IsZero -}}\n{{- $scratch.Add \"meta\" (slice (.Date | time.Format (default "
},
{
"path": "blog/layouts/partials/post_nav_links.html",
"chars": 581,
"preview": "{{- $pages := where site.RegularPages \"Type\" \"in\" site.Params.mainSections }}\n{{- if and (gt (len $pages) 1) (in $pages "
},
{
"path": "blog/layouts/partials/templates/schema_json.html",
"chars": 4164,
"preview": "{{- /*\n Override of PaperMod's templates/schema_json.html.\n\n PaperMod's BreadcrumbList builds the trail by string-mani"
},
{
"path": "blog/layouts/shortcodes/button.html",
"chars": 997,
"preview": "{{- $text := .Get \"text\" | default \"Learn More\" -}}\n{{- $url := .Get \"url\" | default \"#\" -}}\n{{- $target := .Get \"target"
},
{
"path": "blog/layouts/shortcodes/youtube.html",
"chars": 653,
"preview": "{{- $id := .Get \"id\" | default (.Get 0) -}}\n{{- $title := .Get \"title\" | default \"YouTube video\" -}}\n\n<div class=\"youtub"
},
{
"path": "blog/static/CNAME",
"chars": 29,
"preview": "blog.modelcontextprotocol.io\n"
},
{
"path": "docs/.well-known/security.txt",
"chars": 91,
"preview": "Contact: https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md"
},
{
"path": "docs/clients.mdx",
"chars": 89820,
"preview": "---\ntitle: \"Example Clients\"\ndescription: \"A list of applications that support MCP integrations\"\n---\n\n{/* prettier-ignor"
},
{
"path": "docs/community/antitrust.mdx",
"chars": 5359,
"preview": "---\ntitle: Antitrust Policy\ndescription: MCP Project Antitrust Policy for participants and contributors\n---\n\n**Effective"
},
{
"path": "docs/community/communication.mdx",
"chars": 6103,
"preview": "---\ntitle: Contributor Communication\ndescription: Communication strategy and framework for the Model Context Protocol co"
},
{
"path": "docs/community/contributing.mdx",
"chars": 22447,
"preview": "---\ntitle: Contributing to MCP\ndescription: How to contribute to the Model Context Protocol project\n---\n\nThe Model Conte"
},
{
"path": "docs/community/contributor-ladder.mdx",
"chars": 19479,
"preview": "---\ntitle: Contributor Ladder\ndescription: Roles, responsibilities, and advancement criteria for MCP contributors, from "
},
{
"path": "docs/community/design-principles.mdx",
"chars": 3864,
"preview": "---\ntitle: Design Principles\ndescription: The core design principles that guide the development of the Model Context Pro"
},
{
"path": "docs/community/governance.mdx",
"chars": 8763,
"preview": "---\ntitle: Governance and Stewardship\ndescription: Learn about the Model Context Protocol's governance structure and how"
},
{
"path": "docs/community/sdk-tiers.mdx",
"chars": 8373,
"preview": "---\ntitle: SDK Tiering System\ndescription: Feature completeness, protocol support, and maintenance commitment levels for"
},
{
"path": "docs/community/sep-guidelines.mdx",
"chars": 12315,
"preview": "---\ntitle: SEP Guidelines\ndescription: Specification Enhancement Proposal (SEP) guidelines for proposing changes to the "
},
{
"path": "docs/community/working-interest-groups.mdx",
"chars": 7807,
"preview": "---\ntitle: Working and Interest Groups\ndescription: Learn about the two forms of collaborative groups within the Model C"
},
{
"path": "docs/development/roadmap.mdx",
"chars": 8850,
"preview": "---\ntitle: Roadmap\ndescription: Our plans for evolving Model Context Protocol\n---\n\n<Info>Last updated: **2026-03-05**</I"
},
{
"path": "docs/docs/develop/build-client.mdx",
"chars": 45785,
"preview": "---\ntitle: \"Build an MCP client\"\ndescription: \"Get started building your own client that can integrate with all MCP serv"
},
{
"path": "docs/docs/develop/build-server.mdx",
"chars": 84846,
"preview": "---\ntitle: \"Build an MCP server\"\ndescription: \"Get started building your own server to use in Claude for Desktop and oth"
},
{
"path": "docs/docs/develop/connect-local-servers.mdx",
"chars": 11757,
"preview": "---\ntitle: Connect to local MCP servers\ndescription: Learn how to extend Claude Desktop with local MCP servers to enable"
},
{
"path": "docs/docs/develop/connect-remote-servers.mdx",
"chars": 8165,
"preview": "---\ntitle: Connect to remote MCP Servers\ndescription: Learn how to connect Claude to remote MCP servers and extend its c"
},
{
"path": "docs/docs/getting-started/intro.mdx",
"chars": 2885,
"preview": "---\ntitle: What is the Model Context Protocol (MCP)?\nsidebarTitle: What is MCP?\n---\n\nMCP (Model Context Protocol) is an "
},
{
"path": "docs/docs/learn/architecture.mdx",
"chars": 24487,
"preview": "---\ntitle: Architecture overview\nsidebarTitle: Architecture\ntype: docs\n---\n\nThis overview of the Model Context Protocol "
},
{
"path": "docs/docs/learn/client-concepts.mdx",
"chars": 14318,
"preview": "---\ntitle: Understanding MCP clients\nsidebarTitle: Clients\n---\n\nMCP clients are instantiated by host applications to com"
},
{
"path": "docs/docs/learn/server-concepts.mdx",
"chars": 14176,
"preview": "---\ntitle: Understanding MCP servers\nsidebarTitle: Servers\n---\n\nMCP servers are programs that expose specific capabiliti"
},
{
"path": "docs/docs/sdk.mdx",
"chars": 4293,
"preview": "---\ntitle: SDKs\ndescription: Official SDKs for building with Model Context Protocol\n---\n\nBuild MCP servers and clients u"
},
{
"path": "docs/docs/tools/inspector.mdx",
"chars": 3788,
"preview": "---\ntitle: MCP Inspector\ndescription: In-depth guide to using the MCP Inspector for testing and debugging Model Context "
},
{
"path": "docs/docs/tutorials/security/authorization.mdx",
"chars": 43088,
"preview": "---\ntitle: Understanding Authorization in MCP\ndescription: Learn how to implement secure authorization for MCP servers u"
},
{
"path": "docs/docs/tutorials/security/security_best_practices.mdx",
"chars": 29498,
"preview": "---\ntitle: Security Best Practices\ndescription: Security considerations, attack vectors, and best practices for MCP impl"
},
{
"path": "docs/docs/tutorials/use-local-mcp-server.mdx",
"chars": 5,
"preview": "todo\n"
},
{
"path": "docs/docs.json",
"chars": 20062,
"preview": "{\n \"$schema\": \"https://mintlify.com/docs.json\",\n \"theme\": \"mint\",\n \"name\": \"Model Context Protocol\",\n \"colors\": {\n "
},
{
"path": "docs/examples.mdx",
"chars": 3537,
"preview": "---\ntitle: Example Servers\ndescription: \"A list of example servers and implementations\"\n---\n\nThis page showcases various"
},
{
"path": "docs/extensions/apps/build.mdx",
"chars": 18815,
"preview": "---\ntitle: Build an MCP App\ndescription: Getting started guide for building interactive UI applications with MCP Apps\n--"
},
{
"path": "docs/extensions/apps/overview.mdx",
"chars": 12274,
"preview": "---\ntitle: MCP Apps\ndescription: Interactive UI applications that render inside MCP hosts like Claude Desktop\n---\n\n<Tip>"
},
{
"path": "docs/extensions/auth/enterprise-managed-authorization.mdx",
"chars": 7432,
"preview": "---\ntitle: Enterprise-Managed Authorization\ndescription: Centralized access control for MCP in enterprise environments v"
},
{
"path": "docs/extensions/auth/oauth-client-credentials.mdx",
"chars": 10531,
"preview": "---\ntitle: OAuth Client Credentials\ndescription: Machine-to-machine authentication for MCP using the OAuth 2.0 client cr"
},
{
"path": "docs/extensions/auth/overview.mdx",
"chars": 3875,
"preview": "---\ntitle: Authorization Extensions\ndescription: Supplementary authorization mechanisms for the Model Context Protocol\n-"
},
{
"path": "docs/extensions/client-matrix.mdx",
"chars": 5137,
"preview": "---\ntitle: Extension Support Matrix\ndescription: Which MCP clients implement which official extensions\n---\n\n{/* prettier"
},
{
"path": "docs/extensions/overview.mdx",
"chars": 8049,
"preview": "---\ntitle: Extensions Overview\ndescription: Optional extensions to the Model Context Protocol\n---\n\n# MCP Extensions\n\nMCP"
},
{
"path": "docs/faqs.mdx",
"chars": 4478,
"preview": "---\ntitle: \"FAQs\"\ndescription: \"Explaining MCP and why it matters in simple terms\"\n---\n\n## What is MCP?\n\nMCP (Model Cont"
},
{
"path": "docs/footer.js",
"chars": 901,
"preview": "// Custom footer copyright notice\n(function() {\n function addCopyright() {\n const footer = document.querySelector('f"
},
{
"path": "docs/images/java/class-diagrams.puml",
"chars": 7397,
"preview": "@startuml Core Components\n\n' Core Interfaces\ninterface McpTransport {\n +Mono<Void> connect(Function<Mono<JSONRPCMessage"
},
{
"path": "docs/legacy/concepts/architecture.mdx",
"chars": 8664,
"preview": "---\ntitle: \"Core architecture\"\ndescription: \"Understand how MCP connects clients, servers, and LLMs\"\n---\n\nThe Model Cont"
},
{
"path": "docs/legacy/concepts/elicitation.mdx",
"chars": 7009,
"preview": "---\ntitle: \"Elicitation\"\ndescription: \"Interactive information gathering in MCP\"\n---\n\nElicitation is a powerful MCP feat"
},
{
"path": "docs/legacy/concepts/prompts.mdx",
"chars": 10495,
"preview": "---\ntitle: \"Prompts\"\ndescription: \"Create reusable prompt templates and workflows\"\n---\n\nPrompts enable servers to define"
},
{
"path": "docs/legacy/concepts/resources.mdx",
"chars": 7540,
"preview": "---\ntitle: \"Resources\"\ndescription: \"Expose data and content from your servers to LLMs\"\n---\n\nResources are a core primit"
},
{
"path": "docs/legacy/concepts/roots.mdx",
"chars": 2102,
"preview": "---\ntitle: \"Roots\"\ndescription: \"Understanding roots in MCP\"\n---\n\nRoots are a concept in MCP that define the boundaries "
},
{
"path": "docs/legacy/concepts/sampling.mdx",
"chars": 6495,
"preview": "---\ntitle: \"Sampling\"\ndescription: \"Let your servers request completions from LLMs\"\n---\n\nSampling is a powerful MCP feat"
},
{
"path": "docs/legacy/concepts/tools.mdx",
"chars": 15351,
"preview": "---\ntitle: \"Tools\"\ndescription: \"Enable LLMs to perform actions through your server\"\n---\n\nTools are a powerful primitive"
},
{
"path": "docs/legacy/concepts/transports.mdx",
"chars": 17503,
"preview": "---\ntitle: \"Transports\"\ndescription: \"Learn about MCP's communication mechanisms\"\n---\n\nTransports in the Model Context P"
},
{
"path": "docs/legacy/tools/debugging.mdx",
"chars": 6765,
"preview": "---\ntitle: Debugging\ndescription: A comprehensive guide to debugging Model Context Protocol (MCP) integrations\n---\n\nEffe"
},
{
"path": "docs/registry/about.mdx",
"chars": 6403,
"preview": "---\ntitle: The MCP Registry\nsidebarTitle: About\n---\n\n<Note>\n The MCP Registry is currently in preview. Breaking changes"
},
{
"path": "docs/registry/authentication.mdx",
"chars": 10688,
"preview": "---\ntitle: How to Authenticate When Publishing to the Official MCP Registry\nsidebarTitle: Authentication\n---\n\n<Note>\n T"
},
{
"path": "docs/registry/faq.mdx",
"chars": 2285,
"preview": "---\ntitle: Frequently Asked Questions\nsidebarTitle: FAQ\n---\n\n<Note>\n The MCP Registry is currently in preview. Breaking"
},
{
"path": "docs/registry/github-actions.mdx",
"chars": 6863,
"preview": "---\ntitle: How to Automate Publishing with GitHub Actions\nsidebarTitle: GitHub Actions\n---\n\n<Note>\n The MCP Registry is"
},
{
"path": "docs/registry/moderation-policy.mdx",
"chars": 2871,
"preview": "---\ntitle: The MCP Registry Moderation Policy\nsidebarTitle: Moderation Policy\n---\n\n<Note>\n The MCP Registry is currentl"
},
{
"path": "docs/registry/package-types.mdx",
"chars": 6892,
"preview": "---\ntitle: MCP Registry Supported Package Types\nsidebarTitle: Package Types\n---\n\n<Note>\n The MCP Registry is currently "
},
{
"path": "docs/registry/quickstart.mdx",
"chars": 9349,
"preview": "---\ntitle: \"Quickstart: Publish an MCP Server to the MCP Registry\"\nsidebarTitle: \"Quickstart: Publish a Server\"\n---\n\n<No"
},
{
"path": "docs/registry/registry-aggregators.mdx",
"chars": 4796,
"preview": "---\ntitle: MCP Registry Aggregators\nsidebarTitle: Registry Aggregators\n---\n\n<Note>\n The MCP Registry is currently in pr"
},
{
"path": "docs/registry/remote-servers.mdx",
"chars": 5090,
"preview": "---\ntitle: Publishing Remote Servers\nsidebarTitle: Remote Servers\n---\n\n<Note>\n The MCP Registry is currently in preview"
},
{
"path": "docs/registry/terms-of-service.mdx",
"chars": 7396,
"preview": "---\ntitle: Official MCP Registry Terms of Service\nsidebarTitle: Terms of Service\n---\n\n<Note>\n The MCP Registry is curre"
},
{
"path": "docs/registry/versioning.mdx",
"chars": 6087,
"preview": "---\ntitle: Versioning Published MCP Servers\nsidebarTitle: Versioning\n---\n\n<Note>\n The MCP Registry is currently in prev"
},
{
"path": "docs/sdk/java/mcp-client.mdx",
"chars": 489,
"preview": "---\ntitle: Java MCP Client\ndescription: Learn how to implement and configure a Model Context Protocol (MCP) client\n---\n\n"
},
{
"path": "docs/sdk/java/mcp-overview.mdx",
"chars": 428,
"preview": "---\ntitle: Java SDK Overview\ndescription: Introduction to the Model Context Protocol (MCP) Java SDK\n---\n\n<Warning>\n### *"
},
{
"path": "docs/sdk/java/mcp-server.mdx",
"chars": 489,
"preview": "---\ntitle: Java MCP Server\ndescription: Learn how to implement and configure a Model Context Protocol (MCP) server\n---\n\n"
},
{
"path": "docs/seps/1024-mcp-client-security-requirements-for-local-server-.mdx",
"chars": 6319,
"preview": "---\ntitle: \"SEP-1024: MCP Client Security Requirements for Local Server Installation\"\nsidebarTitle: \"SEP-1024: MCP Clien"
},
{
"path": "docs/seps/1034--support-default-values-for-all-primitive-types-in.mdx",
"chars": 6090,
"preview": "---\ntitle: \"SEP-1034: Support default values for all primitive types in elicitation schemas\"\nsidebarTitle: \"SEP-1034: Su"
},
{
"path": "docs/seps/1036-url-mode-elicitation-for-secure-out-of-band-intera.mdx",
"chars": 16427,
"preview": "---\ntitle: \"SEP-1036: URL Mode Elicitation for secure out-of-band interactions\"\nsidebarTitle: \"SEP-1036: URL Mode Elicit"
},
{
"path": "docs/seps/1046-support-oauth-client-credentials-flow-in-authoriza.mdx",
"chars": 4066,
"preview": "---\ntitle: \"SEP-1046: Support OAuth client credentials flow in authorization\"\nsidebarTitle: \"SEP-1046: Support OAuth cli"
},
{
"path": "docs/seps/1302-formalize-working-groups-and-interest-groups-in-mc.mdx",
"chars": 16665,
"preview": "---\ntitle: \"SEP-1302: Formalize Working Groups and Interest Groups in MCP Governance\"\nsidebarTitle: \"SEP-1302: Formalize"
},
{
"path": "docs/seps/1303-input-validation-errors-as-tool-execution-errors.mdx",
"chars": 7319,
"preview": "---\ntitle: \"SEP-1303: Input Validation Errors as Tool Execution Errors\"\nsidebarTitle: \"SEP-1303: Input Validation Errors"
},
{
"path": "docs/seps/1319-decouple-request-payload-from-rpc-methods-definiti.mdx",
"chars": 6119,
"preview": "---\ntitle: \"SEP-1319: Decouple Request Payload from RPC Methods Definition\"\nsidebarTitle: \"SEP-1319: Decouple Request Pa"
},
{
"path": "docs/seps/1330-elicitation-enum-schema-improvements-and-standards.mdx",
"chars": 16053,
"preview": "---\ntitle: \"SEP-1330: Elicitation Enum Schema Improvements and Standards Compliance\"\nsidebarTitle: \"SEP-1330: Elicitatio"
},
{
"path": "docs/seps/1577--sampling-with-tools.mdx",
"chars": 19332,
"preview": "---\ntitle: \"SEP-1577: Sampling With Tools\"\nsidebarTitle: \"SEP-1577: Sampling With Tools\"\ndescription: \"Sampling With Too"
},
{
"path": "docs/seps/1613-establish-json-schema-2020-12-as-default-dialect-f.mdx",
"chars": 7988,
"preview": "---\ntitle: \"SEP-1613: Establish JSON Schema 2020-12 as Default Dialect for MCP\"\nsidebarTitle: \"SEP-1613: Establish JSON "
},
{
"path": "docs/seps/1686-tasks.mdx",
"chars": 64190,
"preview": "---\ntitle: \"SEP-1686: Tasks\"\nsidebarTitle: \"SEP-1686: Tasks\"\ndescription: \"Tasks\"\n---\n\n<div className=\"flex items-center"
},
{
"path": "docs/seps/1699-support-sse-polling-via-server-side-disconnect.mdx",
"chars": 4505,
"preview": "---\ntitle: \"SEP-1699: Support SSE polling via server-side disconnect\"\nsidebarTitle: \"SEP-1699: Support SSE polling via s"
},
{
"path": "docs/seps/1730-sdks-tiering-system.mdx",
"chars": 10801,
"preview": "---\ntitle: \"SEP-1730: SDKs Tiering System\"\nsidebarTitle: \"SEP-1730: SDKs Tiering System\"\ndescription: \"SDKs Tiering Syst"
},
{
"path": "docs/seps/1850-pr-based-sep-workflow.mdx",
"chars": 9658,
"preview": "---\ntitle: \"SEP-1850: PR-Based SEP Workflow\"\nsidebarTitle: \"SEP-1850: PR-Based SEP Workflow\"\ndescription: \"PR-Based SEP "
},
{
"path": "docs/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.mdx",
"chars": 9117,
"preview": "---\ntitle: \"SEP-1865: MCP Apps - Interactive User Interfaces for MCP\"\nsidebarTitle: \"SEP-1865: MCP Apps - Interactive Us"
},
{
"path": "docs/seps/2085-governance-succession-and-amendment.mdx",
"chars": 6965,
"preview": "---\ntitle: \"SEP-2085: Governance Succession and Amendment Procedures\"\nsidebarTitle: \"SEP-2085: Governance Succession and"
},
{
"path": "docs/seps/2133-extensions.mdx",
"chars": 19672,
"preview": "---\ntitle: \"SEP-2133: Extensions\"\nsidebarTitle: \"SEP-2133: Extensions\"\ndescription: \"Extensions\"\n---\n\n<div className=\"fl"
},
{
"path": "docs/seps/2148-contributor-ladder.mdx",
"chars": 27071,
"preview": "---\ntitle: \"SEP-2148: MCP Contributor Ladder\"\nsidebarTitle: \"SEP-2148: MCP Contributor Ladder\"\ndescription: \"MCP Contrib"
},
{
"path": "docs/seps/2149-working-group-charter-template.mdx",
"chars": 22969,
"preview": "---\ntitle: \"SEP-2149: MCP Group Governance and Charter Template\"\nsidebarTitle: \"SEP-2149: MCP Group Governance and Chart"
},
{
"path": "docs/seps/2260-Require-Server-requests-to-be-associated-with-Client-requests.mdx",
"chars": 13447,
"preview": "---\ntitle: \"SEP-2260: Require Server requests to be associated with a Client request.\"\nsidebarTitle: \"SEP-2260: Require "
},
{
"path": "docs/seps/414-request-meta.mdx",
"chars": 5432,
"preview": "---\ntitle: \"SEP-414: Document OpenTelemetry Trace Context Propagation Conventions\"\nsidebarTitle: \"SEP-414: Document Open"
},
{
"path": "docs/seps/932-model-context-protocol-governance.mdx",
"chars": 4660,
"preview": "---\ntitle: \"SEP-932: Model Context Protocol Governance\"\nsidebarTitle: \"SEP-932: Model Context Protocol Governance\"\ndescr"
},
{
"path": "docs/seps/973-expose-additional-metadata-for-implementations-res.mdx",
"chars": 6923,
"preview": "---\ntitle: \"SEP-973: Expose additional metadata for Implementations, Resources, Tools and Prompts\"\nsidebarTitle: \"SEP-97"
},
{
"path": "docs/seps/985-align-oauth-20-protected-resource-metadata-with-rf.mdx",
"chars": 6190,
"preview": "---\ntitle: \"SEP-985: Align OAuth 2.0 Protected Resource Metadata with RFC 9728\"\nsidebarTitle: \"SEP-985: Align OAuth 2.0 "
},
{
"path": "docs/seps/986-specify-format-for-tool-names.mdx",
"chars": 4532,
"preview": "---\ntitle: \"SEP-986: Specify Format for Tool Names\"\nsidebarTitle: \"SEP-986: Specify Format for Tool Names\"\ndescription: "
},
{
"path": "docs/seps/990-enable-enterprise-idp-policy-controls-during-mcp-o.mdx",
"chars": 3488,
"preview": "---\ntitle: \"SEP-990: Enable enterprise IdP policy controls during MCP OAuth flows\"\nsidebarTitle: \"SEP-990: Enable enterp"
},
{
"path": "docs/seps/991-enable-url-based-client-registration-using-oauth-c.mdx",
"chars": 17484,
"preview": "---\ntitle: \"SEP-991: Enable URL-based Client Registration using OAuth Client ID Metadata Documents\"\nsidebarTitle: \"SEP-9"
},
{
"path": "docs/seps/994-shared-communication-practicesguidelines.mdx",
"chars": 4585,
"preview": "---\ntitle: \"SEP-994: Shared Communication Practices/Guidelines\"\nsidebarTitle: \"SEP-994: Shared Communication Practices/G"
},
{
"path": "docs/seps/index.mdx",
"chars": 9115,
"preview": "---\ntitle: Specification Enhancement Proposals (SEPs)\nsidebarTitle: SEP Index\ndescription: Index of all MCP Specificatio"
},
{
"path": "docs/snippets/snippet-intro.mdx",
"chars": 284,
"preview": "One of the core principles of software development is DRY (Don't Repeat\nYourself). This is a principle that apply to doc"
},
{
"path": "docs/spec-version-warning.js",
"chars": 6792,
"preview": "// Spec Version Warning Banner\n// Displays a warning banner on older spec versions and draft pages.\n//\n// Mintlify autom"
},
{
"path": "docs/specification/2024-11-05/architecture/index.mdx",
"chars": 6141,
"preview": "---\ntitle: Architecture\n---\n\nThe Model Context Protocol (MCP) follows a client-host-server architecture where each\nhost "
},
{
"path": "docs/specification/2024-11-05/basic/index.mdx",
"chars": 3438,
"preview": "---\ntitle: Overview\n---\n\nAll messages between MCP clients and servers **MUST** follow the\n[JSON-RPC 2.0](https://www.jso"
},
{
"path": "docs/specification/2024-11-05/basic/lifecycle.mdx",
"chars": 6661,
"preview": "---\ntitle: Lifecycle\ntype: docs\nweight: 30\n---\n\nThe Model Context Protocol (MCP) defines a rigorous lifecycle for client"
},
{
"path": "docs/specification/2024-11-05/basic/messages.mdx",
"chars": 1321,
"preview": "---\ntitle: Messages\ntype: docs\nweight: 20\n---\n\nAll messages in MCP **MUST** follow the\n[JSON-RPC 2.0](https://www.jsonrp"
},
{
"path": "docs/specification/2024-11-05/basic/transports.mdx",
"chars": 3558,
"preview": "---\ntitle: Transports\ntype: docs\nweight: 40\n---\n\nMCP currently defines two standard transport mechanisms for client-serv"
},
{
"path": "docs/specification/2024-11-05/basic/utilities/cancellation.mdx",
"chars": 2465,
"preview": "---\ntitle: Cancellation\nweight: 10\n---\n\nThe Model Context Protocol (MCP) supports optional cancellation of in-progress r"
},
{
"path": "docs/specification/2024-11-05/basic/utilities/ping.mdx",
"chars": 1552,
"preview": "---\ntitle: Ping\nweight: 5\n---\n\nThe Model Context Protocol includes an optional ping mechanism that allows either party\nt"
},
{
"path": "docs/specification/2024-11-05/basic/utilities/progress.mdx",
"chars": 2342,
"preview": "---\ntitle: Progress\nweight: 30\n---\n\nThe Model Context Protocol (MCP) supports optional progress tracking for long-runnin"
},
{
"path": "docs/specification/2024-11-05/client/roots.mdx",
"chars": 4123,
"preview": "---\ntitle: Roots\ntype: docs\nweight: 40\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for clients to "
},
{
"path": "docs/specification/2024-11-05/client/sampling.mdx",
"chars": 5780,
"preview": "---\ntitle: Sampling\ntype: docs\nweight: 40\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers "
},
{
"path": "docs/specification/2024-11-05/index.mdx",
"chars": 5059,
"preview": "---\ntitle: Specification\n---\n\n[Model Context Protocol](https://modelcontextprotocol.io) (MCP) is an open protocol that\ne"
},
{
"path": "docs/specification/2024-11-05/server/index.mdx",
"chars": 1593,
"preview": "---\ntitle: Overview\n---\n\nServers provide the fundamental building blocks for adding context to language models via\nMCP. "
},
{
"path": "docs/specification/2024-11-05/server/prompts.mdx",
"chars": 5887,
"preview": "---\ntitle: Prompts\nweight: 10\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers to expose pr"
},
{
"path": "docs/specification/2024-11-05/server/resources.mdx",
"chars": 7771,
"preview": "---\ntitle: Resources\ntype: docs\nweight: 20\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers"
},
{
"path": "docs/specification/2024-11-05/server/tools.mdx",
"chars": 5790,
"preview": "---\ntitle: Tools\ntype: docs\nweight: 40\n---\n\nThe Model Context Protocol (MCP) allows servers to expose tools that can be "
},
{
"path": "docs/specification/2024-11-05/server/utilities/completion.mdx",
"chars": 3418,
"preview": "---\ntitle: Completion\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers to offer\nargument au"
},
{
"path": "docs/specification/2024-11-05/server/utilities/logging.mdx",
"chars": 3748,
"preview": "---\ntitle: Logging\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers to send\nstructured log "
},
{
"path": "docs/specification/2024-11-05/server/utilities/pagination.mdx",
"chars": 2334,
"preview": "---\ntitle: Pagination\n---\n\nThe Model Context Protocol (MCP) supports paginating list operations that may return\nlarge re"
},
{
"path": "docs/specification/2025-03-26/architecture/index.mdx",
"chars": 5701,
"preview": "---\ntitle: Architecture\n---\n\nThe Model Context Protocol (MCP) follows a client-host-server architecture where each\nhost "
},
{
"path": "docs/specification/2025-03-26/basic/authorization.mdx",
"chars": 15070,
"preview": "---\ntitle: Authorization\n---\n\n## Introduction\n\n### Purpose and Scope\n\nThe Model Context Protocol provides authorization "
},
{
"path": "docs/specification/2025-03-26/basic/index.mdx",
"chars": 3972,
"preview": "---\ntitle: Overview\n---\n\nThe Model Context Protocol consists of several key components that work together:\n\n- **Base Pro"
},
{
"path": "docs/specification/2025-03-26/basic/lifecycle.mdx",
"chars": 7940,
"preview": "---\ntitle: Lifecycle\n---\n\nThe Model Context Protocol (MCP) defines a rigorous lifecycle for client-server\nconnections th"
},
{
"path": "docs/specification/2025-03-26/basic/transports.mdx",
"chars": 13766,
"preview": "---\ntitle: Transports\n---\n\nMCP uses JSON-RPC to encode messages. JSON-RPC messages **MUST** be UTF-8 encoded.\n\nThe proto"
},
{
"path": "docs/specification/2025-03-26/basic/utilities/cancellation.mdx",
"chars": 2454,
"preview": "---\ntitle: Cancellation\n---\n\nThe Model Context Protocol (MCP) supports optional cancellation of in-progress requests\nthr"
},
{
"path": "docs/specification/2025-03-26/basic/utilities/ping.mdx",
"chars": 1542,
"preview": "---\ntitle: Ping\n---\n\nThe Model Context Protocol includes an optional ping mechanism that allows either party\nto verify t"
},
{
"path": "docs/specification/2025-03-26/basic/utilities/progress.mdx",
"chars": 2490,
"preview": "---\ntitle: Progress\n---\n\nThe Model Context Protocol (MCP) supports optional progress tracking for long-running\noperation"
},
{
"path": "docs/specification/2025-03-26/changelog.mdx",
"chars": 1666,
"preview": "---\ntitle: Key Changes\n---\n\nThis document lists changes made to the Model Context Protocol (MCP) specification since\nthe"
},
{
"path": "docs/specification/2025-03-26/client/roots.mdx",
"chars": 4101,
"preview": "---\ntitle: Roots\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for clients to expose\nfilesystem \"roo"
},
{
"path": "docs/specification/2025-03-26/client/sampling.mdx",
"chars": 5887,
"preview": "---\ntitle: Sampling\n---\n\nThe Model Context Protocol (MCP) provides a standardized way for servers to request LLM\nsamplin"
},
{
"path": "docs/specification/2025-03-26/index.mdx",
"chars": 5210,
"preview": "---\ntitle: Specification\n---\n\n[Model Context Protocol](https://modelcontextprotocol.io) (MCP) is an open protocol that\ne"
}
]
// ... and 300 more files (download for full content)
About this extraction
This page contains the full source code of the modelcontextprotocol/modelcontextprotocol GitHub repository, extracted and formatted as plain text for AI agents and large language models (LLMs). The extraction includes 500 files (4.9 MB), approximately 1.3M tokens, and a symbol index with 825 extracted functions, classes, methods, constants, and types. Use this with OpenClaw, Claude, ChatGPT, Cursor, Windsurf, or any other AI tool that accepts text input. You can copy the full output to your clipboard or download it as a .txt file.
Extracted by GitExtract — free GitHub repo to text converter for AI. Built by Nikandr Surkov.