Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[v2] MRTR wipe-cache example reads unvalidated elicitation content and defaults malformed scope to all

Chiusa Adatta ai principianti
  • Qualcosa non va?
#2,542 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
documentation, security

Direzione di ricerca

Apri docs/servers/input-required.md e individua l'esempio di cancellazione della cache «Carry state across rounds with requestState». Leggi l'uso precedente di acceptedContent() consapevole dello schema nella pagina, quindi aggiorna sia la gestione della conferma sia quella dell'ambito per convalidare il contenuto del client in fase di esecuzione. Il lavoro è completato quando le richieste con un ambito non valido o mancante richiedono nuovamente un input invece di usare «all» per impostazione predefinita.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

spec-2026-07-28 v2
What happened?

The v2 input_required documentation correctly states that
ctx.mcpReq.inputResponses is client-provided and untrusted, and recommends
using the schema-aware overload of acceptedContent().

However, the sequential wipe-cache example uses the unchecked generic
overload for both confirmation and scope:

const confirmed = acceptedContent<{ confirm: boolean }>(
    ctx.mcpReq.inputResponses,
    'confirm'
);

It later treats that response as proof that the operator confirmed:

if (confirmed?.confirm !== true) {
    return inputRequired({
        inputRequests: {
            confirm: inputRequired.elicit({
                message: 'Really wipe the cache?',
                requestedSchema: {
                    type: 'object',
                    properties: {
                        confirm: {
                            type: 'boolean'
                        }
                    },
                    required: ['confirm']
                }
            })
        }
    });
}

return inputRequired({
    inputRequests: {
        scope: inputRequired.elicit({
            message: 'Which scope?',
            requestedSchema: {
                type: 'object',
                properties: {
                    scope: {
                        type: 'string'
                    }
                },
                required: ['scope']
            }
        })
    },
    requestState: await stateCodec.mint({
        step: 'confirmed'
    })
});

The generic type parameter only affects TypeScript typing. It does not perform
runtime validation of the client-provided value.

For example, a malformed accepted response could contain:

{
  "action": "accept",
  "content": {
    "confirm": "false"
  }
}

The string "false" is truthy in JavaScript. Because the example only checks:

confirmed?.confirm !== true

this particular value does not equal the boolean true, so the current
!== true check fails closed.

However, the example still demonstrates reading untrusted client content using
a compile-time generic instead of the runtime-validating overload. A copied or
slightly modified version using a normal truthiness check such as:

if (!confirmed?.confirm) {
    // request confirmation
}

would treat "false" as confirmation.

The same example later reads the requested scope with the unchecked overload:

const scope = acceptedContent<{ scope: string }>(
    ctx.mcpReq.inputResponses,
    'scope'
);

return {
    content: [{
        type: 'text',
        text: `Wiped ${scope?.scope ?? 'all'}`
    }]
};

If the scope response is missing, malformed, or of an unexpected type, the
example falls back to "all". That feels unsafe for a destructive example and
conflicts with the page's earlier guidance to validate inputResponses using
the schema-aware overload.

This is primarily a documentation and defensive API-usage issue, not a claim
that a malicious MCP client gains a capability it did not already possess.

What did you expect?

I expected the destructive wipe-cache example to follow the page's own
guidance and validate all client-provided elicitation content at runtime.

For example:

const confirmationSchema = z.object({
    confirm: z.boolean()
});

const scopeSchema = z.object({
    scope: z.string()
});

const confirmed = acceptedContent(
    ctx.mcpReq.inputResponses,
    'confirm',
    confirmationSchema
);

if (confirmed?.confirm !== true) {
    return inputRequired({
        inputRequests: {
            confirm: inputRequired.elicit({
                message: 'Really wipe the cache?',
                requestedSchema: confirmationSchema
            })
        }
    });
}

const scope = acceptedContent(
    ctx.mcpReq.inputResponses,
    'scope',
    scopeSchema
);

if (scope === undefined) {
    return inputRequired({
        inputRequests: {
            scope: inputRequired.elicit({
                message: 'Which scope?',
                requestedSchema: scopeSchema
            })
        }
    });
}

return {
    content: [{
        type: 'text',
        text: `Wiped ${scope.scope}`
    }]
};

The example should also fail closed when scope content is missing or invalid,
rather than defaulting to "all".

Code to reproduce
Documentation page:

`docs/servers/input-required.md`

Relevant section:

`Carry state across rounds with requestState`

Relevant example:


const confirmed = acceptedContent<{ confirm: boolean }>(
    ctx.mcpReq.inputResponses,
    'confirm'
);

const scope = acceptedContent<{ scope: string }>(
    ctx.mcpReq.inputResponses,
    'scope'
);

return {
    content: [{
        type: 'text',
        text: `Wiped ${scope?.scope ?? 'all'}`
    }]
};


Minimal demonstration that the generic type does not validate at runtime:


const clientContent: unknown = {
    confirm: 'false'
};

const confirmed =
    clientContent as {
        confirm: boolean;
    };

console.log(typeof confirmed.confirm);
// "string"

console.log(Boolean(confirmed.confirm));
// true


The cast changes the TypeScript type but does not transform or validate the
runtime value.
SDK version

main at commit 1e1392e3f91583884fe82a0b4b91335875c3fba6

Area

Documentation

Lingua principale
TypeScript
Stelle
13.5k
Fork
2.3k
Merge medio
2g 18h
PR unite (30g)
55

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/typescript-sdk

Tutte le issue di modelcontextprotocol/typescript-sdk

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.