[shwetangsinha0509]

Part of #1047

Fixes points (1) and (2) of #1047 in StreamableHttpClientTransport:

• Mcp-Method and Mcp-Name are now sent on requests only. Notifications no longer carry them.
• Mcp-Name is resolved per method as SEP-2243 defines: name for tools/call and prompts/get, uri for resources/read. Previously any request whose params had a name or uri got the header (e.g. resources/subscribe).
• Per SEP-2663, tasks/get and tasks/cancel set Mcp-Name from params.taskId. tasks/update is not defined in the SDK yet.
• All other methods carry no Mcp-Name.

Point (3), gating the headers on the negotiated protocol version, is left out pending the question in #1047, since it depends on #1090 / #1091.

Tests (StreamableHttpClientTransportTest)

• Updated the notification test, which asserted the previous behaviour.
• Added cases for a notification carrying uri, prompts/get, tasks/get / tasks/cancel, resources/subscribe, and tools/list.

:kotlin-sdk-client:jvmTest, ktlintCheck, detekt and checkKotlinAbi pass locally. No public API change.

[jetbrains-air]

Thanks for the PR — I left one blocking comment to resolve before merge.

Produced by Air Automations. Name: Code review / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/409567ec-d3a7-40ac-ba95-8518ec577ac2?run=bc6240b7-f9c0-40e2-ac83-c1a5c0c701f3

[jetbrains-air]

Blocking: the new Mcp-Name source table is missing the tasks/* rows. SEP-2663 § Streamable HTTP: Routing Headers says the client MUST set Mcp-Name to params.taskId for tasks/get, tasks/update and tasks/cancel. This SDK ships tasks/get and tasks/cancel as ClientRequests whose params carry taskId (GetTaskRequestParams / CancelTaskRequestParams in kotlin-sdk-core/.../types/tasks.kt), so this else -> null now affirmatively encodes "no Mcp-Name" for them, and the KDoc above presents the table as the complete per-method mapping.

Failure scenario: a client polls tasks/get with {"taskId": "task-123"} against a load-balanced deployment. Without Mcp-Name, the intermediary cannot pin the poll to the instance holding the task state and routes it to another one — the poll fails or reports an unknown task (SEP-2663 calls this routing "typically required for correctness"). Against a server that validates the SEP-2243 standard headers — the TypeScript SDK's MCP_NAME_HEADER_SOURCE table includes the tasks/* rows — the POST is rejected with 400 / -32020 HeaderMismatch. I reproduced the omission on this branch by running the transport test with a tasks/get request: Mcp-Name is absent.

Suggested fix: add the row to mcpNameHeaderSource, and cover it with a test next to the new prompts/get case:

Method.Defined.TasksGet.value, Method.Defined.TasksCancel.value -> params.stringValue("taskId")

[shwetangsinha0509]

Thanks, confirmed against SEP-2663 § Streamable HTTP: Routing Headers. Added tasks/get and tasks/cancel → params.taskId to the Mcp-Name source mapping, updated the KDoc, and covered both with a test in 1331d1e.

tasks/update isn't defined in the SDK yet (no Method.Defined entry), so it will need the same row once the SEP-2663 methods land.

[jetbrains-air]

Happy to approve — nothing blocking from my side.

---

Produced by Air Automations. Name: Code review / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/409567ec-d3a7-40ac-ba95-8518ec577ac2?run=b8ff9c69-e377-4100-8aee-d0fc0954f4cb

[jetbrains-air]

Looks great — the per-method Mcp-Name mapping and the requests-only scoping both match the ratified spec, so this is good to merge.

---

Produced by Air Automations. Name: Code review / Run: https://air.jetbrains.cloud/org/05cf1a7f-6ab5-713b-abd3-29d0c8a05e2d/automations/409567ec-d3a7-40ac-ba95-8518ec577ac2?run=4e43b43b-6ef3-477d-af24-99f8dc0fb076