# GitHub and Docker MCP Catalog Readiness Kit Version 1.0 | November 7, 2026 A checklist and worksheet for a developer, SaaS publisher or agency preparing an MCP listing. Source checks were completed November 8, 2026 UTC. The edition date is November 7; the source dates below identify the later verification. MCP means Model Context Protocol: a shared way for an assistant to request a named function, called a tool. An MCP server offers those tools. A registry stores discovery and connection information. Being listed does not prove a tool is safe or guarantee that customers will find it. GitHub's gallery, Docker's catalog and Microsoft certification have separate review paths. GitHub staff describe initial onboarding as manual curation, with later versions syncing from the official MCP Registry once onboarded. GitHub has not published selection criteria in the sources below. These worksheets prepare a clear request; they do not predict acceptance. ## 1. Official MCP Registry readiness Who does this: the owner chooses the audience; the developer prepares and validates the record. Done when: the owner can find the intended version and connection details in the official Registry. - [ ] Write the audience and one useful task: ____________________ - [ ] Confirm that you own or control the server and its public connection address, also called its endpoint. - [ ] Choose the registry name: ____________________ - [ ] Choose a namespace, the ownership prefix before the slash. A domain namespace such as `com.example` requires proof that you control `example.com`. GitHub identity namespaces such as `io.github.example-owner` are another supported option. - [ ] For a domain name, choose the documented DNS or HTTP verification method. A DNS TXT record is a public text entry in the domain's address book; HTTP verification places the public proof at the documented website address. Keep the signing key private. - [ ] Prepare `server.json`, the registry's machine-readable description. Follow the current published schema. - [ ] Give the description one sentence saying what the server does and for whom. The cited schema limits this field to 100 characters. - [ ] Choose local package, remote connection, or both based on the real implementation. A local package runs on the user's machine and needs its runtime. A remote server runs at your service and accepts network requests. - [ ] For a remote service, use Streamable HTTP unless you must support an older client. It is the current recommended remote transport, meaning the way protocol messages travel between client and server. - [ ] For a package, publish its artifact to the supported package registry and include the ownership metadata that registry requires. The official MCP Registry stores metadata, not the package itself. - [ ] Use a unique version for each publication. Published metadata is immutable, so corrections need a new version. Semantic versioning, such as `1.2.0`, is recommended. - [ ] Add accurate documentation and optional repository details. Do not invent a public repository for a hosted private implementation. - [ ] Supply an optional icon using an HTTPS address. Check that it is yours to use and readable at small sizes. - [ ] Prepare public support, privacy, security and license or hosted-service terms pages. - [ ] Validate the record against the schema before the owner publishes it. - [ ] After publication, verify the name, version, status and actual package or remote address in the public Registry. Our own illustrative remote metadata below uses reserved example addresses. Replace every example value. This is a starting record, not proof of namespace ownership or a working service. ```json { "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json", "name": "com.example/catalog-help", "title": "Catalog Help", "description": "Find public product documentation for developers integrating Example's catalog API.", "version": "1.0.0", "websiteUrl": "https://example.com/connect/", "icons": [ { "src": "https://example.com/icon.png", "mimeType": "image/png", "sizes": ["128x128"] } ], "remotes": [ { "type": "streamable-http", "url": "https://example.com/mcp" } ] } ``` ## 2. README outline for a developer audience Who does this: the developer writes from actual behavior; the owner checks promises and support details. Done when: another developer can identify the intended task, prerequisites, permissions and expected result without guessing. This is our own outline, with one example line per heading. Replace the examples; they are not claims about an existing service. A README is the introductory document a repository or listing shows to its reader. ```markdown # Catalog Help Find public product documentation while integrating Example's catalog API. ## Who this helps This server is for developers maintaining integrations with our product catalog. ## Install in VS Code Provide a reviewed install link and the exact configuration format for the supported client. ## Install in other clients Give the connection address or package command and name each client you actually tested. ## Tools and inputs find_document accepts a topic and returns matching public documentation links. ## Authentication This illustrative public-information service requires no account or secret. ## Security considerations The tool returns links and does not edit products, store drafts or submit forms. ## Data handling Describe actual inputs, logs, retention and hosting providers here. ## License and service terms Link the source license if public and separately describe hosted-service terms. ## Example prompts Find documentation explaining the catalog's product identifier format. ## Configuration example Include a complete client-specific JSON example using reserved example addresses. ## Versions and compatibility List the published version and client versions you checked. ## Known limitations Describe unsupported tasks and how the person can finish them on the website. ## Support and security reports Give receiving contact routes and a public security reporting policy. ``` For VS Code, native configuration uses a `servers` object; portable Copilot configuration uses `mcpServers`. Do not label one format as universal. A VS Code install link is useful only if its generated configuration agrees with the documented setup. Review the command or endpoint, trust prompts and requested access before accepting a connection. Authentication, permission to start a server and approval of individual tools are different decisions. Describe each tool's effects. `readOnlyHint` describes a tool that does not modify its environment. `destructiveHint` describes potentially destructive changes; `idempotentHint` describes whether repeating the same request has no additional effect. `openWorldHint` describes whether it can interact with external entities. These annotations are hints, not enforcement. Implement the boundary in the server and keep the description honest. ## 3. GitHub onboarding request worksheet Who does this: the developer prepares evidence; the owner reviews and sends the request through the currently documented channel. Done when: a request exists with accurate public information and a recorded status. A submitted request is not a listing. GitHub's October 2025 tutorial directs publishers to publish to the official Registry first, then request inclusion through its partnerships contact. Discussion 1257 also contains onboarding requests and the staff clarification about manual curation. The fields below are our preparation worksheet, not an official required form. ```text Please consider this server for GitHub MCP Registry onboarding. Official MCP Registry name: [namespace/server-name] Latest published version: [version] Public Registry entry or verification link: [URL] One-line purpose and audience: [what it does, for whom] Delivery: [remote connection / local package / both] Transport and connection URL, if remote: [transport] [URL] Package name, ecosystem and runtime, if local: [details] Authentication and permissions: [none / method and scopes] Website and documentation: [public URLs] Repository: [public URL, or explain that hosted source is not public] Source license or hosted-service terms: [accurate terms and URL] Tools and effects: [names, inputs, read/write behavior, limits] Supported client setup: [public installation instructions] Icon: [public HTTPS URL] Support and security reporting: [public contact routes] Owner or maintainer: [public organization identity] Request date: [UTC date] Request URL or reference: [fill in after sending] Status checked on: [UTC time] Status: [requested / more information needed / listed / declined] ``` In our case, the [jwatte.com onboarding request](https://github.com/github/github-mcp-server/discussions/1257#discussioncomment-19467621) named `com.jwatte/site` version `1.1.0`, its remote address, public documentation, hosted implementation, free-use terms and read-only tools. It had no replies at the November 8, 2026 03:06:42 UTC read. The older discussion being marked answered does not mean our request was accepted. ## 4. Docker MCP Catalog remote entry Who does this: the developer prepares the catalog entry; the owner reviews its claims and pull request. Done when: the three files validate and the review status is recorded. Validation alone does not mean acceptance. A pull request proposes repository changes for maintainers to review. Docker's contribution guide describes remote entries using `server.yaml`, `tools.json` and `readme.md` in the entry's directory. YAML is a text format for named settings; JSON is another structured text format. Our own illustrative `server.yaml`, for a public service with no authentication: ```yaml name: example-catalog-help type: remote dynamic: tools: true meta: category: documentation tags: - documentation - remote about: title: Example Catalog Help description: Find public product documentation for catalog API developers icon: https://example.com/icon.png remote: transport_type: streamable-http url: https://example.com/mcp ``` Our own `tools.json` example follows Docker's documented remote dynamic-discovery convention. The empty array does not claim the service has no tools. ```json [] ``` Our own `readme.md` example points to human setup instructions: ```markdown # Example Catalog Help Docs: https://example.com/connect/ ``` For a service that requires OAuth, use Docker's current OAuth instructions instead of this no-authentication example. OAuth is a sign-in and delegated-permission process; it lets a client request access without asking the user to paste an account password. Docker requires dynamic tool configuration for OAuth entries. Its guide says the no-OAuth remote example does not need an `oauth` or `dynamic.tools` setting; our example keeps `dynamic: tools: true`, as our own pull request did, so tools are discovered from the server rather than listed in `tools.json`. Validator checklist from Docker's source: - [ ] Entry name and directory agree. - [ ] Title capitalization passes. The validator permits lowercase `and` and `for`, but rejects titles containing `MCP` or `Server`. - [ ] YAML passes Prettier's formatting check. - [ ] Secret declarations and configuration environment variables agree where present. - [ ] Source license validation passes where applicable. It is skipped for a remote entry without source metadata; that does not grant reuse rights. - [ ] Icon and tool-file checks pass. - [ ] Remote transport and address are present. - [ ] OAuth and dynamic-tool settings agree if OAuth is used. Two gotchas from our case: the title changed from `jwatte.com website tools` to `Jwatte.com Website Tools` to pass capitalization. The validator invokes `npx` and Prettier, so a Go-only environment also needs Node.js and npm tooling available; our initial plain Go container produced an empty error message. The source confirms the dependency. We did not rerun that container incident for this kit. Developer-only validation command, for your own prepared entry in a reviewed Docker catalog checkout: ```sh go run ./cmd/validate --name example-catalog-help ``` This executes repository code, may download build dependencies and may make network requests. Review it first and use it only with your own server or one you have permission to test. It was not executed while preparing this kit. The illustrative JSON blocks were parsed and the registry record checked against its published schema; the YAML was parsed and passed `prettier --check`. Those checks do not prove runtime behavior or catalog acceptance. In our case, [Docker pull request 6766](https://github.com/docker/mcp-registry/pull/6766) reported passing local checks after the fixes. It was still open and unmerged at November 8, 2026 03:06:12 UTC. Neither that pull request nor our GitHub request establishes inclusion, approval or traffic. ## 5. Microsoft certification readiness Who does this: the owner decides whether Microsoft business customers need this distribution; the developer and publisher prepare the package together. Done when: eligibility, authentication fit and maintenance responsibility are confirmed before submission work begins. This is Microsoft's certification preview for surfaces including Copilot Studio, Copilot chat, Cowork and Azure Foundry. It is separate from GitHub's curated developer gallery. - [ ] The publisher has a Microsoft Partner Center account with completed business verification. - [ ] The organization is enrolled in the Microsoft 365 and Copilot program. - [ ] The organization owns or controls the submitted endpoint. - [ ] The developer has read the current intake instructions. The page directs new submissions to an intake form and warns that only limited submissions can be processed. - [ ] The package includes the Teams-style manifest, tool file, icon assets and public documentation. - [ ] Prepare `intro.md` with features, setup, known issues and limitations. The page's package table calls it required, while a later heading calls it optional. Preparing it is the conservative choice; confirm current intake expectations. - [ ] Support, privacy and terms links describe the actual service. - [ ] Authentication matches Microsoft's documented OAuth configuration through Azure Key Vault, its managed secret store. Follow the current instructions for granting access and referencing the vault; do not put secrets into a worksheet or repository. - [ ] The integration does not depend on Dynamic Client Registration, which enrolls clients automatically, or PKCE, a sign-in protection mechanism. This certification page says both are unsupported today. That is a limitation of this documented path, not a recommendation to weaken other clients' authentication. - [ ] Review tool behavior and provide the test evidence requested by Microsoft. - [ ] Assign someone to maintain the certified implementation and resubmit material changes. - [ ] If considering the legacy process, check the date: the page read November 8, 2026 says it remains available through November 18, 2026. Skip or defer this path if: - Your audience is developers finding a tool through GitHub, and no customer needs the Microsoft certification surfaces. - Your service is public, read-only and requires no sign-in, while the documented package expects OAuth through Azure Key Vault. Ask Microsoft to clarify an appropriate route before changing the service merely to fit the package. - You cannot establish publisher eligibility or do not own or control the service. - You cannot support the required authentication path, ongoing maintenance or reviewer testing. - You need a guaranteed acceptance date. The preview offers no such guarantee. ## Sources and read times Times are UTC on November 8, 2026. Documentation and state can change; check again before publishing or submitting. - [Official Registry quickstart](https://modelcontextprotocol.io/registry/quickstart), 03:08:02. - [Registry authentication and namespace proof](https://modelcontextprotocol.io/registry/authentication), 03:08:04. - [Remote server publishing](https://modelcontextprotocol.io/registry/remote-servers), 03:08:01. - [Versioning published servers](https://modelcontextprotocol.io/registry/versioning), 03:08:00. - [Published registry JSON schema](https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json), 03:08:35. - [GitHub MCP concepts](https://docs.github.com/en/copilot/concepts/customizations/mcp), 03:07:07. - [GitHub publishing and management tutorial](https://github.blog/ai-and-ml/generative-ai/how-to-find-install-and-manage-mcp-servers-with-the-github-mcp-registry/), 03:07:09. - [Staff clarification on manual onboarding](https://github.com/github/github-mcp-server/discussions/1257#discussioncomment-16977009), 03:06:12. - [VS Code configuration reference](https://code.visualstudio.com/docs/agents/reference/mcp-configuration), 03:08:19. - [VS Code trust and server management](https://code.visualstudio.com/docs/agents/run/manage-mcp-servers), 03:08:21. - [MCP tool annotations](https://modelcontextprotocol.io/specification/2026-07-28/schema#toolannotations), 03:08:05. - [Docker contribution instructions](https://github.com/docker/mcp-registry/blob/main/CONTRIBUTING.md), 03:07:09. - [Docker validator source](https://github.com/docker/mcp-registry/blob/main/cmd/validate/main.go), 03:07:10. - [Our Docker pull request](https://github.com/docker/mcp-registry/pull/6766), 03:06:12; [our GitHub request](https://github.com/github/github-mcp-server/discussions/1257#discussioncomment-19467621), 03:06:42. - [Microsoft MCP certification preview](https://learn.microsoft.com/en-us/microsoft-copilot-studio/mcp-certification), 03:07:08.