mirror of
https://github.com/google/adk-docs.git
synced 2026-09-14 16:16:59 +08:00
Shahin Saadati
6b8b086052
* Add Kotlin snippet for remote MCP with a suspend headerProvider The MCP tools page had no Kotlin content. This adds a Kotlin tab to the "Agent Configuration for Remote MCP" group, where it differs from the sibling tabs in a way worth showing: adk-kotlin 0.7.0 made McpToolset's headerProvider a suspend function, so a token can be minted per request rather than baked in as a static header the way the Python and Java tabs do. Two things the snippet has to get right, both of which a reader porting from the Java tab would otherwise hit: - McpToolset's constructor is internal. The Java tab's `new McpToolset(streamableParams)` has no Kotlin equivalent; instances come from McpToolsetConfig.toToolset(), as the KDoc directs. Confirmed by compiling the direct form, which fails with "Cannot access 'constructor (...)': it is internal". - Supplying a headerProvider disables session reuse, so that headers can vary per context. That is a real cost, so the comment says so and points at static headers on StreamableHttp for callers who want a single cached session. Badged Kotlin v0.7.0: the page had no Kotlin badge, and the suspend headerProvider signature is 0.7.0. Inline to match the page's other tabs, so CI will not compile it. Extracted, compiled and ran it against the 0.7.0 pin in a throwaway project: OK toolset=McpToolset. * Tighten the MCP snippet after self-review Three presentation fixes; no change to what the snippet does. - Comment cut from five lines to three. The Python and Java tabs in this group carry a single comment line each, so the original block was well out of step with its neighbours. - Closed the config constructor before chaining .toToolset(), removing an eight-space hanging indent that no formatter would produce. Nothing catches it, since inline snippets are never linted. - Said that fetchToken() awaits. The v0.7.0 badge on this page rests entirely on that: headerProvider existed at 0.6.0, just not as a suspend function. Compiling the snippet against a 0.6.0 pin confirms it -- with a suspend fetchToken() it fails, with a plain one it compiles. A reader whose token source is synchronous does not need 0.7.0, and nothing in the visible code said which case this is. Re-ran the snippet against the 0.7.0 pin: OK toolset=McpToolset.