Installing MCP dev skills in an agent
Each MCP development skill ships a `SKILL.md` file plus a `references/` folder of supporting material (auth flows, tool-design patterns, widget templates, manifest schemas) that the agent reads on demand. In Claude Code install with the commands `/plugin marketplace add anthropics/claude-plugins-official` then `/plugin install mcp-server-dev`. For other agents, clone the skill directories (each containing SKILL.md plus references/) into the agent's skills location.
Discovery questions before scaffolding an MCP server
Before writing code, decide five things: what the server connects to (cloud API, local process, filesystem, hardware); who will use it (just you, your team, or anyone who installs it); the action surface size (a handful of operations versus wrapping a large API); user interaction needs (plain text results, structured input via elicitation, or rich UI widgets); and upstream auth (API keys, OAuth 2.0, or none). These answers determine the deployment model and tool-design pattern.
mcp-server-dev plugin: three composing agent skills
A reference set of MCP development agent skills ships as the `mcp-server-dev` plugin at https://github.com/anthropics/claude-plugins-official/tree/main/plugins/mcp-server-dev. It provides three composing skills: `build-mcp-server` (entry point that interrogates the use case, picks a deployment model and tool-design pattern, and routes to specialized skills), `build-mcp-app` (adds interactive UI widgets rendered inline in chat), and `build-mcpb` (packages a local stdio server with its runtime so users can install it without Node or Python).
Where the build-server and build-client guides live in the docs
The MCP documentation splits building into distinct guides: 'Build servers' at /docs/<version>/develop/build-server (create MCP servers to expose your data and tools), 'Build clients' at /docs/<version>/develop/build-client (applications that connect to MCP servers), 'Build MCP Apps' at /extensions/apps/overview (interactive apps that run inside AI clients), and the architecture/concepts page at /docs/<version>/learn/architecture. Version-dated paths such as 2026-07-28 are used in the URL.
MCP definition and purpose
MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems, letting AI applications such as Claude or ChatGPT connect to data sources (local files, databases), tools (search engines, calculators) and workflows (specialized prompts). The official analogy is that MCP is 'a USB-C port for AI applications'.
When to use tools vs resources vs prompts
Choose the primitive by who initiates: use Tools for actions with side effects the model chooses to take (writing to databases, calling external APIs, modifying files, triggering logic); use Resources for read-only passive context the application pulls in (file contents, database schemas, API documentation); use Prompts for reusable parameterized templates that the user explicitly invokes to showcase how to best use the server.
Three server primitives: tools, resources, prompts and who controls each
An MCP server exposes functionality through three building blocks. Tools are functions the LLM actively calls and are model-controlled (examples: search flights, send messages, create calendar events). Resources are passive read-only data sources and are application-controlled (examples: retrieve documents, access knowledge bases, read calendars). Prompts are pre-built instruction templates and are user-controlled (examples: plan a vacation, summarize my meetings, draft an email).
Multi-server workflow: prompt selects resources then drives tool calls
A typical multi-server flow is: (1) the user invokes a prompt with arguments, e.g. {"prompt": "plan-vacation", "arguments": {"destination": "Barcelona", "departure_date": "2024-06-15", "return_date": "2024-06-22", "budget": 3000, "travelers": 2}}; (2) the user selects resources to include such as `calendar://my-calendar/June-2024`, `travel://preferences/europe`, `travel://past-trips/Spain-2023`; (3) the model reads those resources for context and then calls tools across the connected servers, e.g. searchFlights(), checkWeather(), bookHotel(), createCalendarEvent(), sendEmail(), requesting user approval where necessary.
Official MCP SDKs and their tiers
The Model Context Protocol has ten official SDKs classified by tier. Tier 1 (most complete, strongest maintenance commitment): TypeScript (modelcontextprotocol/typescript-sdk), Python (modelcontextprotocol/python-sdk), C# (modelcontextprotocol/csharp-sdk), Go (modelcontextprotocol/go-sdk). Tier 2: Java (modelcontextprotocol/java-sdk), Rust (modelcontextprotocol/rust-sdk), Ruby (modelcontextprotocol/ruby-sdk). Tier 3: Swift (modelcontextprotocol/swift-sdk), PHP (modelcontextprotocol/php-sdk), Kotlin (modelcontextprotocol/kotlin-sdk). Tiers reflect feature completeness, protocol support, and maintenance commitment.
SDK documentation URLs per language
Each official MCP SDK has a documentation site under the sdk.modelcontextprotocol.io domain: ts.sdk.modelcontextprotocol.io (TypeScript), py.sdk.modelcontextprotocol.io (Python), csharp.sdk.modelcontextprotocol.io (C#), go.sdk.modelcontextprotocol.io (Go), java.sdk.modelcontextprotocol.io (Java), rust.sdk.modelcontextprotocol.io (Rust), ruby.sdk.modelcontextprotocol.io (Ruby), php.sdk.modelcontextprotocol.io (PHP), kotlin.sdk.modelcontextprotocol.io (Kotlin). Swift has no dedicated docs site listed, only its GitHub repository.
Baseline capabilities guaranteed by every official MCP SDK
All official MCP SDKs provide the same core functionality while following the idioms of their language: creating MCP servers that expose tools, resources, and prompts; building MCP clients that can connect to any MCP server; both local and remote transport protocols; and protocol compliance with type safety. This means a feature choice such as which primitives to expose or which transport to use is not constrained by the SDK language.
Events a server should log
Important events to record in server logs are startup steps, resource access, tool execution, error conditions, and performance metrics. Logging best practice is structured logs with consistent formats, contextual data, timestamps and request IDs; stack traces and error context for errors; and operation timing, resource usage, message sizes and latency for performance.
Stateless modern handlers cannot hold state between calls
A stateless modern MCP handler constructed per request cannot hold state between calls. For example, a tool that mutates a resource would run against a throwaway server instance and the mutation would be invisible to the next read, so such mutation tools must be backed by external storage rather than in-process state.
Python MCPServer with AuthSettings and token verifier
In the Python SDK, `MCPServer(name=..., instructions=..., debug=True, token_verifier=token_verifier, auth=AuthSettings(issuer_url=AnyHttpUrl(issuer), required_scopes=['mcp:tools'], resource_server_url=AnyHttpUrl(server_url)))` publishes the Protected Resource Metadata document, answers unauthenticated requests with a 401 whose WWW-Authenticate header points at that document, and passes every bearer token to the supplied verifier.
C#: AddMcp ResourceMetadata plus JwtBearer validation
In the C# SDK, call `AddAuthentication` with `DefaultChallengeScheme = McpAuthenticationDefaults.AuthenticationScheme` and `DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme`, then `.AddJwtBearer(...)` with Authority, ValidIssuer, ValidAudiences and a custom AudienceValidator, then `.AddMcp(options => options.ResourceMetadata = new() { Resource = serverUrl, AuthorizationServers = { authorizationServerUrl }, ScopesSupported = ["mcp:tools"] })`. Register the server with `builder.Services.AddMcpServer().WithTools<MathTools>().WithHttpTransport()` and expose it via `app.MapMcp().RequireAuthorization()` after `app.UseAuthentication()` and `app.UseAuthorization()`.
TypeScript: protecting a Streamable HTTP MCP server with bearer auth
In the TypeScript SDK, mount `mcpAuthMetadataRouter({ oauthMetadata, resourceServerUrl: mcpServerUrl, scopesSupported: ['mcp:tools'], resourceName: 'MCP Demo Server' })` from '@modelcontextprotocol/sdk/server/auth/router.js' to publish metadata, then build middleware with `requireBearerAuth({ verifier: tokenVerifier, requiredScopes: [], resourceMetadataUrl: getOAuthProtectedResourceMetadataUrl(mcpServerUrl) })` from '@modelcontextprotocol/sdk/server/auth/middleware/bearerAuth.js', and apply it to the POST, GET and DELETE handlers on the MCP route. The verifier object implements `verifyAccessToken(token)` and returns `{ token, clientId, scopes, expiresAt }`.
MCP is stateless: state is carried by explicit handles passed as tool arguments
MCP has no protocol-level sessions and is stateless. A server that needs state spanning multiple requests mints an explicit handle (e.g. a shopping cart ID or workflow ID), returns it in a tool result, and receives it back as an ordinary tool argument on each subsequent call.
create-mcp-app agent skill installation paths
The `create-mcp-app` skill scaffolds MCP App projects. Install in Claude Code via `/plugin marketplace add modelcontextprotocol/ext-apps` then `/plugin install mcp-apps@modelcontextprotocol-ext-apps`, or `npx skills add modelcontextprotocol/ext-apps`. Manual skill directories: Claude Code `~/.claude/skills/`, VS Code/GitHub Copilot `~/.copilot/skills/`, Gemini CLI `~/.gemini/skills/`, Cline `~/.cline/skills/`, Goose `~/.config/goose/skills/`, Codex `~/.codex/skills/`, Cursor `~/.cursor/skills/`.
MCP App project layout
A typical MCP App project has `package.json`, `tsconfig.json`, `vite.config.ts`, `server.ts` (MCP server with tool + resource), `mcp-app.html` (UI entry point), and `src/mcp-app.ts` (UI logic). Build with `INPUT=mcp-app.html vite build` and run with `npx tsx server.ts`; `package.json` needs `"type": "module"`. The server reads the built file from `dist/mcp-app.html`.
registerAppTool and registerAppResource from @modelcontextprotocol/ext-apps/server
The server helpers `registerAppTool`, `registerAppResource` and the constant `RESOURCE_MIME_TYPE` are imported from `@modelcontextprotocol/ext-apps/server`. `registerAppTool(server, name, {title, description, inputSchema, _meta: { ui: { resourceUri } }}, handler)` registers a UI-backed tool; `registerAppResource(server, resourceUri, resourceUri, { mimeType: RESOURCE_MIME_TYPE }, handler)` serves the bundled HTML, returning `{ contents: [{ uri, mimeType: RESOURCE_MIME_TYPE, text: html }] }`.
MCP App dependencies to install
An MCP App project installs runtime deps `@modelcontextprotocol/ext-apps` and `@modelcontextprotocol/sdk`, and dev deps `typescript`, `vite`, `vite-plugin-singlefile`, `express`, `cors`, `@types/express`, `@types/cors`, and `tsx`. Node.js 18 or higher is required.
@modelcontextprotocol/ext-apps App class is optional
The `App` class from the `@modelcontextprotocol/ext-apps` package is a convenience wrapper, not a requirement; you can implement the postMessage protocol directly to avoid dependencies or get tighter control. Starter templates exist for React, Vue, Svelte, Preact, Solid, and vanilla JavaScript in the ext-apps examples directory.
When to choose an MCP App over plain text or a web app
MCP Apps fit exploring complex data (interactive drill-down), configuration with many interdependent options (a form instead of back-and-forth questions), rich media viewing (PDF, 3D models, images), real-time monitoring dashboards, and multi-step workflows needing persistent state and navigation. If your use case does not need context preservation, bidirectional data flow, host capability integration, or sandbox security guarantees, a regular standalone web app may be simpler.
Server-side steps to require enterprise-managed authorization
An MCP server that requires enterprise-managed authorization must declare the extension in its authorization metadata so clients know to use the enterprise-managed flow, and may optionally publish its resource descriptor to IdP admin APIs so enterprise administrators can configure access policies in their IdP admin console.
Server steps to accept client-credentials tokens
An MCP server accepting client-credentials tokens must, on each request, verify the JWT signature and claims against the authorization server's public keys (usually via a JWKS endpoint), check that the token includes the scopes required for the requested operation, and — optionally but recommended for discoverability — advertise the extension in the `server/discover` response under result.capabilities.extensions with the key "io.modelcontextprotocol/oauth-client-credentials": {}.
When to use Tasks rather than a synchronous tool
Tasks fit long-running operations (CI pipelines, batch data processing, model training taking minutes or hours), human-in-the-loop workflows with approval or review gates, servers wrapping external job systems that already have job IDs (cloud deployments, async APIs, queued work), unreliable connections such as mobile or intermittent networks where task IDs survive disconnects, and batch processing where partial progress is meaningful and reported via status messages.
Server capability JSON for Tasks extension
Example server/discover response advertising Tasks: {"jsonrpc":"2.0","id":1,"result":{"capabilities":{"extensions":{"io.modelcontextprotocol/tasks":{}}}}}.
CreateTaskResult fields returned instead of a normal result
When a server decides a request will be long-running it responds with a `CreateTaskResult`, identified by `resultType: "task"`, containing a unique `taskId`, an initial status, a TTL (`ttlMs`), and a suggested polling interval (`pollIntervalMs`). The task must be durably created before the response is sent.
Server obligations for tasks/get, tasks/update and tasks/cancel
A task-capable server must serve `tasks/get` by returning current task state on each poll, including `result` on `completed` or `error` on `failed`; accept `tasks/update` with `inputResponses` keyed to outstanding `inputRequests`, acknowledge with an empty result, and ignore responses for unknown or already-satisfied keys; and acknowledge `tasks/cancel` with an empty result, honoring it when possible while allowing the task to still reach a non-`cancelled` terminal status.
server.json metadata format fields
Server metadata published to the MCP Registry is stored in a standardized `server.json` format (schema at github.com/modelcontextprotocol/registry, docs/reference/server-json/draft/server.schema.json). It contains: the server's unique name in reverse-DNS style (e.g. `io.github.user/server-name`), where to locate the server (e.g. npm package name or remote server URL), execution instructions (command-line args, environment variables), and other discovery data such as description and server capabilities.
Registry hosts metadata, not packages
Package registries such as npm, PyPI and Docker Hub host the actual code and binaries; the MCP Registry only hosts metadata pointing to those packages. For example, a `weather-mcp` package hosted on npm can be mapped by registry metadata as server 'weather v1.2.0' -> `npm:weather-mcp`. Supported package types and registries are listed in the Package Types guide.
MCP Registry: what it is and what it stores
The MCP Registry is the official centralized metadata repository for publicly accessible MCP servers, backed by Anthropic, GitHub, PulseMCP, and Microsoft. It provides a single publishing point for server creators, namespace management via DNS verification, a REST API for MCP clients and aggregators to discover servers, and standardized installation/configuration information. It is currently in preview, so breaking changes or data resets may occur.
Registry eligibility: public install method required, no private servers
The MCP Registry accepts both open-source and closed-source servers as long as the installation method is publicly available (e.g. an npm package or a Docker image on a public registry) or the server itself is publicly accessible (e.g. a remote server not restricted to private networks). Private servers — those on private networks like `mcp.acme-corp.internal` or on private package registries (e.g. `npx -y @acme/mcp --registry https://artifactory.acme-corp.internal/npm`) — are not supported; host your own private MCP registry for those.
DNS TXT record format for MCP Registry domain auth
DNS-based authentication for the MCP Registry proves domain ownership with a TXT record on the apex domain in the form `example.com. IN TXT "v=MCPv1; k=ed25519; p=<base64 public key>"` for Ed25519 keys, or `k=ecdsap384` for ECDSA P-384 keys. Add the record via your DNS provider and allow several minutes for propagation before logging in with `mcp-publisher login dns --domain "example.com" --private-key "<hex private key>"`.
Generating registry auth keys with OpenSSL
For MCP Registry domain authentication, generate an Ed25519 key with `openssl genpkey -algorithm Ed25519 -out key.pem` and derive the base64 public key with `openssl pkey -in key.pem -pubout -outform DER | tail -c 32 | base64`. For ECDSA P-384 use `openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:secp384r1 -out key.pem` and extract the compressed public key with `openssl ec -in key.pem -text -noout -conv_form compressed`. The private key passed to `mcp-publisher` is the hex `priv:` bytes with spaces, colons and newlines stripped.
Cloud KMS signing options for MCP Registry login
Instead of a local key file, `mcp-publisher` can sign registry logins with cloud KMS. Google Cloud KMS: `mcp-publisher login dns google-kms --domain=example.com --resource="projects/<proj>/locations/global/keyRings/<ring>/cryptoKeys/<key>/cryptoKeyVersions/1"` (create key with `--default-algorithm=ec-sign-ed25519 --purpose=asymmetric-signing` and enable Application Default Credentials via `gcloud auth application-default login`). Azure Key Vault: `mcp-publisher login dns azure-key-vault --domain=example.com --vault MyKeyVault --key MyKey` with a key created via `az keyvault key create --curve P-384`. The same subcommands exist with `login http` instead of `login dns`. Running the login command before the proof record exists prints the "Expected proof record" to copy.
Registry auth method determines server.json name namespace
When publishing to the official MCP Registry, the authentication method you pick dictates the allowed namespace of the `name` field in `server.json`. GitHub-based authentication requires a name of the form `io.github.username/*` or `io.github.orgname/*` (e.g. `io.github.alice/weather-server`). Domain-based authentication (DNS or HTTP) requires a reverse-DNS name of the form `com.example.*/*` for the domain you control (e.g. `io.modelcontextprotocol/everything`). A mismatch between login method and name prefix will block publishing.
GitHub OAuth device login with mcp-publisher
GitHub authentication for the MCP Registry uses an OAuth device flow started by running `mcp-publisher login github` from the server project directory. The CLI prints a device code (e.g. `ABCD-1234`) and instructs you to visit https://github.com/login/device, enter the code, and authorize the application; on success it prints "Successfully authenticated!" and "✓ Successfully logged in".
HTTP domain auth via /.well-known/mcp-registry-auth
HTTP-based authentication for the MCP Registry requires hosting a file at `https://<your-domain>/.well-known/mcp-registry-auth` whose contents are a single line `v=MCPv1; k=ed25519; p=<base64 public key>` (or `k=ecdsap384` for ECDSA P-384). Once the file is served, log in with `mcp-publisher login http --domain "example.com" --private-key "<hex private key>"`.
MCP Registry terminology: API vs Official Registry vs third-party registry
MCP registry terms have distinct meanings: 'MCP Registry API' is any API implementing the OpenAPI spec defined by the MCP Registry; 'Official MCP Registry API' is the REST API served at https://registry.modelcontextprotocol.io, a superset of the MCP Registry API, whose OpenAPI spec is downloadable at https://registry.modelcontextprotocol.io/openapi.yaml; 'MCP registry' (lowercase) is a third-party service providing an MCP Registry API; 'Official MCP Registry' (or 'The MCP Registry') is the service at https://registry.modelcontextprotocol.io.
Servers cannot be deleted or unpublished from the MCP Registry
There is currently no way to delete or unpublish a server from the Official MCP Registry; the behaviour is still under open discussion in the registry GitHub repository (issue 104). Plan naming and publishing carefully because entries are permanent.
Update server metadata by publishing a new server.json version
To update server metadata in the MCP Registry, submit a new server.json with a unique version string. Once published, version metadata is immutable, similar to npm, so you cannot edit an existing published version in place.
Custom publisher metadata key and 4KB limit
When publishing to the MCP Registry you may include custom metadata under the key `_meta.io.modelcontextprotocol.registry/publisher-provided`, which is preserved by the registry. There is a hard 4KB size limit (4096 bytes of JSON) and publishing fails if the limit is exceeded.
OCI image ownership label io.modelcontextprotocol.server.name
To prove ownership of a Docker/OCI MCP server image, the image must carry the annotation/label `io.modelcontextprotocol.server.name` whose value matches the server name in server.json, e.g. in a Dockerfile: LABEL io.modelcontextprotocol.server.name="io.github.username/kubernetes-manager-mcp".
MCPB package type: hosting, 'mcp' in URL, and fileSha256
MCPB bundles use "registryType": "mcpb" in server.json and must be hosted as GitHub or GitLab release artifacts; the `identifier` is the full download URL (e.g. https://github.com/username/image-processor-mcp/releases/download/v1.0.0/image-processor.mcpb) and MUST contain the string "mcp", either via the .mcpb extension or the repository name. The package entry MUST include `fileSha256` with the SHA-256 hash of the artifact, computable with `openssl dgst -sha256 image-processor.mcpb`.
server.json package entry structure for registry publishing
In server.json for the MCP Registry, each entry in the `packages` array has `registryType` (one of `npm`, `pypi`, `nuget`, `oci`, `mcpb`), `identifier`, usually `version`, and a `transport` object such as `{"type": "stdio"}`. The document itself carries `$schema` (e.g. https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json), `name` (e.g. io.github.username/email-integration-mcp), `title`, `description`, and `version`.
npm package type in MCP Registry and mcpName ownership check
npm-distributed MCP servers use "registryType": "npm" in server.json, and only the public npm registry (https://registry.npmjs.org) is supported. Ownership is verified by a top-level `mcpName` property in package.json whose value MUST exactly match the `name` field of server.json (e.g. "mcpName": "io.github.username/email-integration-mcp").
PyPI package type and mcp-name README marker
Python MCP servers published to PyPI use "registryType": "pypi" in server.json, and only https://pypi.org is supported. Ownership verification requires the string `mcp-name: $SERVER_NAME` to appear in the package README (which becomes the PyPI description); it may be hidden inside an HTML comment such as `<!-- mcp-name: io.github.username/database-query-mcp -->`, but the server name portion MUST match server.json's `name`.
NuGet package type and README verification
NuGet-distributed MCP servers use "registryType": "nuget" in server.json with the identifier being the NuGet package id (e.g. Username.AzureDevOpsMcp); only the official NuGet registry (https://api.nuget.org/v3/index.json) is supported. Ownership is verified by an `mcp-name: $SERVER_NAME` string in the package README, optionally inside an HTML comment, matching server.json's `name`.
Docker/OCI package type, supported registries and identifier format
Container-packaged MCP servers use "registryType": "oci" in server.json. Supported registries are Docker Hub (docker.io), GitHub Container Registry (ghcr.io), Google Artifact Registry (any *.pkg.dev domain), Azure Container Registry (*.azurecr.io) and Microsoft Container Registry (mcr.microsoft.com). The `identifier` format is `registry/namespace/repository:tag`, e.g. docker.io/user/app:1.0.0 or ghcr.io/user/app:1.0.0; a digest may be used instead of a tag. Because the version is embedded in the tag, the OCI example omits a separate `version` field in the package entry.
Tasks extension for long-running requests
Beyond server and client primitives, MCP supports optional extensions that build on the core protocol. The Tasks extension lets servers return a durable handle for long-running requests so clients can poll for status and retrieve the result later.
Example server design: database context server
A concrete design pattern for an MCP server that provides context about a database: expose tools for querying the database, a resource that contains the database schema, and a prompt that includes few-shot examples for interacting with the tools.
Change notifications are opt-in via subscriptions/listen
Change notifications are opt-in. The client opens a long-lived notification stream by sending a `subscriptions/listen` request whose params include a `notifications` filter naming the event types it wants, e.g. {"notifications": {"toolsListChanged": true}}. The server then delivers matching JSON-RPC notifications on that stream. Servers do not push change notifications to clients that have not subscribed.
MCP is stateless: every request carries _meta
As of protocol version 2026-07-28 MCP is a stateless protocol. Every request must carry the protocol version and the capabilities relevant to that request in its `_meta` field so the server can process each request on its own without inferring anything from previous requests. Clients should also identify themselves in the same field unless configured not to.
server/discover request and response shape
Servers advertise supported versions and capabilities through the mandatory `server/discover` request, which every server must implement and clients may send before any other request. A request looks like {"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{...}}}. The result contains `resultType` ("complete"), `supportedVersions` (array such as ["2026-07-28"]), `capabilities` (e.g. {"tools":{"listChanged":true},"resources":{}}), `_meta.io.modelcontextprotocol/serverInfo` with name and version, plus cache hints `ttlMs` (e.g. 3600000) and `cacheScope` (e.g. "public").
server.json schema URL and required top-level fields
A registry server.json document sets `$schema` to https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json and includes top-level fields `name` (reverse-DNS style, e.g. io.github.username/email-integration-mcp), `title`, `description`, `version`, and `packages`.
Custom metadata goes under a reverse-DNS key in _meta
The subregistry OpenAPI spec allows injecting custom metadata into a server record via the `_meta` field. Custom data should be nested under a key reflecting the subregistry, e.g. `"_meta": { "com.example.subregistry/custom": { "user_rating": 4.5, "download_count": 12345, "security_scan": { ... } } }`.
server.json requires a unique version string
An MCP server published to the MCP Registry MUST define a `version` string in its `server.json`. The version string MUST be unique for each publication; once published, the version string and other metadata cannot be changed (no overwriting an existing version).
Minimal server.json example with npm package and stdio transport
A minimal server.json looks like: {"$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json", "name": "io.github.username/email-integration-mcp", "title": "Email Integration", "description": "Send emails and manage email accounts", "version": "1.0.0", "packages": [{"registryType": "npm", "identifier": "@username/email-integration-mcp", "version": "1.0.0", "transport": {"type": "stdio"}}]}. The package entry declares registryType, identifier, its own version, and a transport object whose type is "stdio".
Registry version format: semver recommended, ranges prohibited
The MCP Registry recommends semantic versioning but accepts any version string. Recommended: `1.0.0`, `2.1.3-alpha`, `1.0.0-beta.1`, `3.0.0-rc.2`, and semantic dates like `2025.11.25` (with caution for `2025.6.18`). Allowed: non-semantic dates `2025.06.18` (caution) and `2025-06-18`, and prefixed versions like `v1.0`. Prohibited (rejected as they look like ranges): `^1.2.3`, `~1.2.3`, `>=1.2.3`, `<=1.2.3`, `>1.2.3`, `<1.2.3`, `1.x`, `1.2.*`, `1 - 2`, `1.2 || 1.3`.