Allow custom or numeric request ID generation (Snowflake MCP server rejects string IDs)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 38/100
Direzione di ricerca
Inizia tracciando il metodo privato generateRequestId() e il contatore interno, quindi esamina come il builder di McpClient e il transport trasmettono gli ID delle richieste. Il lavoro è completato quando l'SDK espone un generatore configurabile in grado di produrre ID numerici preservando il comportamento esistente; verifica che gli ID delle richieste e delle risposte rimangano compatibili.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Expected Behavior
The Java SDK should provide a way to configure how request IDs are generated. This could include:
- A public interface or callback for supplying a custom RequestIdGenerator.
- Configuration options to choose between UUID-based, string-based, or numeric-only IDs.
This would help support MCP servers that require strict numeric IDs or forbid UUID/string-based request IDs.
Current Behavior
Currently, the Java SDK:
- Uses a private generateRequestId() method.
- Uses an internal private counter.
- Produces UUID-counter formatted IDs like "62d0970d-0".
- Provides no public extension point to override or customize ID generation.
This causes compatibility issues with MCP servers (such as Snowflake's MCP implementation) that accept only numeric IDs.
Example (hypothetical API):
McpClient client = McpClient.builder()
.withRequestIdGenerator(() -> String.valueOf(counter.incrementAndGet()))
.build();
Context
When integrating with the Snowflake MCP server, requests are rejected because the Java SDK always generates UUID-based IDs.
Workarounds include:
- Implementing a custom transport such as SimpleHttpTransport.
- Remapping request and response IDs manually.
These solutions work but duplicate SDK logic and introduce unnecessary complexity. Providing a built-in, configurable ID generation mechanism would make the SDK more flexible and easier to use.
- Lingua principale
- Java
- Stelle
- 3.7k
- Fork
- 1.1k
- Merge medio
- 1g 15h
- PR unite (30g)
- 9
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di modelcontextprotocol/java-sdk
-
area/transport bug P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
modelcontextprotocol/java-sdk#1136 ·
-
area/client bug P2
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
modelcontextprotocol/java-sdk#1124 · 1 commento ·
-
ServerCapabilities.logging is added unconditionally, overriding the caller's explicit capabilities Apertabug P2 ready for work
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
modelcontextprotocol/java-sdk#1086 · 1 commento ·
-
enhancement good first issue P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
modelcontextprotocol/java-sdk#1067 ·
-
bug P2 ready for work
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
modelcontextprotocol/java-sdk#898 · 1 commento ·
Tutte le issue di modelcontextprotocol/java-sdk
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
elastic/gradle-plugins#157 ·
-
enhancement Tools
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
apache/rocketmq-dashboard#5008 ·
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
DETECT_PARAMETER_NAMES=false silently disables @ConstructorProperties-based Creator detection too Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
FasterXML/jackson-databind#6229 ·