remove() is a no-op after a handle is renamed, and the entry stays callable

remove() silently does nothing once a prompt, resource or resource template handle has been renamed. The entry stays in the list results and stays callable, and list_changed still fires, so clients are told the list changed when it didn't. A second rename also leaves the old key registered, aliasing one entry under two live names.

test/e2e/requirements.ts treats this as a guarantee — mcpserver:prompt:handle-update-remove: "The handle from prompt()/registerPrompt() can .update() and .remove(), triggering list_changed."

Repro

Save under test/integration/test/server/ and run pnpm exec vitest run <file>:

import { Client, InMemoryTransport } from '@modelcontextprotocol/client';
import { McpServer } from '@modelcontextprotocol/server';
import { test } from 'vitest';

test('repro', async () => {
    const server = new McpServer({ name: 'repro', version: '0.0.0' });
    const client = new Client({ name: 'repro', version: '0.0.0' });

    const prompt = server.registerPrompt('first', {}, () => ({ messages: [] }));

    const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
    await Promise.all([client.connect(clientTransport), server.connect(serverTransport)]);

    const names = async () => (await client.listPrompts()).prompts.map(p => p.name);

    prompt.update({ name: 'second' });
    console.log('after first rename: ', await names());

    prompt.update({ name: 'third' });
    console.log('after second rename:', await names());

    prompt.remove();
    console.log('after remove:       ', await names());

    console.log('getPrompt("second"):', (await client.getPrompt({ name: 'second' })).messages);
});

Output on main at 7b781ed:

after first rename:  [ 'second' ]
after second rename: [ 'second', 'third' ]
after remove:        [ 'second', 'third' ]
getPrompt("second"): []

The last line is a successful call. The prompt that was renamed away and then removed still answers.

Cause

The update closure captures the registration key and never reassigns it, so delete this._registeredX[key] targets a key the entry no longer occupies and the live entry is left alone.

• packages/server/src/server/mcp.ts L759 (prompts)
• L677 (resources, keyed by uri rather than name)
• L710 (resource templates)

RegisteredTool gets this right at L886, where name is reassigned after the move.

The same stale value feeds the updates.name !== name guard on the line above each delete, so renaming back to the original name skips the block entirely and does nothing.

Why the tests pass

The two e2e scenarios claiming those requirements only update non-key fields. resources.test.ts updates name and callback, but a resource is keyed by uri. prompts.test.ts updates description and callback, never name. No test changes a key and then removes.

Scope

main has it for prompts, resources and resource templates. v1.x has it for all four, tools included.

Start in packages/server/src/server/mcp.ts at the prompt, resource, and resource-template update closures around lines 677, 710, and 759, comparing their bookkeeping with RegisteredTool around line 886. Add an integration test under test/integration/test/server/ based on the repro, then run it with pnpm exec vitest run. Done means renamed entries are removed, old keys are not callable, and list_changed reflects the actual list.