A pair of contributions from davidahmann addresses a subtle but important protocol concern: when an MCP server exposes capabilities during initialization, should the order be deterministic? The answer is yes — and it matters more than you might think.
davidahmann has been contributing to MCP's protocol infrastructure, with recent work including collision-resistant request IDs for long-running operations (PR #3405). Their focus appears to be on protocol reliability and predictability — exactly the qualities enterprise deployments require.
When an MCP server starts up, it tells clients what capabilities it supports — tools, resources, prompts. The issue: if the order of these capabilities varies between restarts, several problems emerge:
In JavaScript, object property order is technically guaranteed for string keys in insertion order (since ES2015). But when building objects dynamically from async operations, the insertion order may vary based on which operation completes first.
The issue proposes adding explicit language to initialization response documentation specifying that capability ordering should be deterministic. This makes the implicit expectation explicit.
The PR adds assertions to ensure tool registration maintains deterministic ordering in reference server implementations. When tools are registered dynamically, the server now explicitly sorts or orders them before exposure.
// Pseudocode for the pattern
function getCapabilities() {
const tools = Object.keys(registeredTools)
.sort() // Ensure deterministic order
.map(name => registeredTools[name]);
return { tools };
}Protocol details like ordering may seem trivial, but they accumulate into either confidence or chaos:
For implementers: Deterministic behavior means fewer "works on my machine" issues. When debugging an MCP integration, you can compare responses across environments knowing the format is stable.
For testing: CI/CD pipelines can use snapshot testing reliably. When a capability list changes, it's a real change — not random reordering.
For caching: Clients can safely hash capability responses for cache keys, knowing identical capabilities produce identical hashes.
For the ecosystem: As MCP servers proliferate across the ecosystem, consistent behavior patterns reduce integration friction. A client that works with one MCP server should work with another.
This contribution reflects a maturation pattern we're seeing across agentic protocols: specification tightening. Early protocol versions prioritize feature velocity — getting capabilities working. Later versions refine behavior, closing gaps where "implementation-defined" becomes "standardized."
We saw similar refinements in:
If merged, reference servers will enforce deterministic ordering. The specification clarification will guide third-party implementations to follow suit. Over time, clients can rely on this behavior without defensive coding.
For teams building MCP integrations: audit your own implementations for non-deterministic patterns. Async operations that build response objects are the usual culprits.