Whatever message this page gives is out now! Go check it out!
Server Information
Last update:
May 18, 2026
Every MCP server should expose identity metadata so that clients and operators know what it is, which version it runs, and where it came from.
Overview
Every MCP server should expose a small amount of identity metadata so that clients and operators know what it is, which version it runs, and where it came from. This information is usually set during server initialization and included in responses to the MCP
initialize call. At a minimum, you want:
- A stable name (logical identifier)
- A semantic version (e.g., 1.0.0)
- Optional additional metadata (description, vendor, environment, etc.)
Choosing a Server Name
The server name is how clients and users recognize your server. It should be:
- Stable: do not change the name casually; treat it as an identifier.
- Descriptive: encode purpose and domain, not internal implementation details.
- Scope-aware: if you have multiple variants, reflect that (e.g., cf-reporting-mcp, cf-billing-mcp).
Good patterns:
- cf-analytics-mcp
- cf-commerce-order-mcp
- cf-ops-healthcheck-mcp
Avoid:
- Very generic names like mcp-server (hard to distinguish in logs/UI).
- Names tied to ephemeral environments (e.g., cf-mcp-dev-20250312); environment can live in separate metadata.
Example:
mcpServer = mcpServerBuilder()
.serverInfo("cf-reporting-mcp", "1.2.0")
...
.build();
Versioning the Server
The version string tells clients which release of your server they are talking to. It’s primarily for observability and rollout management, not for runtime routing inside the protocol.
Recommended approach:
- Use semver style: MAJOR.MINOR.PATCH
- MAJOR – breaking changes to tools, input/output schemas, or behavior
- MINOR – new tools or non-breaking enhancements
- PATCH – bug fixes or internal improvements
Update the version on every deployment that might affect client behavior.
Example progression:
- 1.0.0 – initial public deployment
- 1.1.0 – adds a new tool generate_monthly_report
- 1.1.1 – fixes a bug in get_account_summary
- 2.0.0 – breaks get_account_summary output schema
In ColdFusion:
mcpServer = mcpServerBuilder()
.serverInfo("cf-billing-mcp", "2.0.0")
...
.build();
Additional Metadata (Optional but Useful)
Some MCP frameworks allow or encourage richer server metadata. Even if not enforced by the protocol, adding this in your own configuration is helpful for humans and tooling.
Examples of additional fields:
- description: short human-readable explanation of purpose
- vendor or ownerTeam: who is responsible (team name, email, Slack channel)
- environment: dev, stage, prod, or region tags
- docsUrl: where to find user-facing documentation
- buildId / gitSha: internal traceability for debugging
You can keep this in a config struct and attach it wherever your MCP runtime expects server info:
serverMeta = {
name : "cf-analytics-mcp",
version : "1.3.4",
description : "Analytics reporting MCP for dashboard and export tools",
ownerTeam : "Data Insights",
environment : "prod",
docsUrl : "https://wiki.corp.adobe.com/display/analytics/CF+MCP+Docs"
};
mcpServer = mcpServerBuilder()
.serverInfo(serverMeta.name, serverMeta.version)
.capabilities({tools:true, prompts:true, resources:false})
...
.build();
Logging this metadata on startup makes support much easier:
writeLog(
file = "mcp",
type = "info",
text = "Starting #serverMeta.name# v#serverMeta.version# in #serverMeta.environment#"
);
We're glad. Tell us how this page helped.
We're sorry. Can you tell us what didn't work for you?
Share additional feedback to help us improve.
0/255
|
