Feature request: use MCP tasks extension to stream ground_location_tool results #197

Activity

1. rehan243 commented on Jun 10, 2026

   

   rehan243

   on Jun 10, 2026

   More actions

   oh interesting, we've actually hacked something similar with MCP tasks for streaming slow POI lookups — totally agree: blocking on the sampling step kills UX, especially when reverse-geocode is ready way faster. What worked for us was firing off the initial MCP task like:

   task = mcp.create_task("ground_location", input)
   task.update({"place_name": fast_reverse_geocode(input['coords'])})
   # Then async for the rest
   sampling = await classify_grounding(input)
   task.update({"sampling_classification": sampling})
   poi = await search_poi(input)
   isochrone = await compute_isochrone(input)
   task.update({"poi": poi, "isochrone": isochrone})

   We ended up using a combo of asyncio and task.update() to stream partial results — not gonna lie, took a few tries to get the agent to handle mid-task updates cleanly. Are you on the 2026-07-28 RC or earlier? Curious if you've got anything weird happening with task update ordering, since our POI search sometimes beats sampling (which feels odd UX-wise).
2. mattpodwysocki commented on Jun 10, 2026

   

   mattpodwysocki

   on Jun 10, 2026

   ContributorAuthor

   More actions

   Picking this up in draft PR #210. The MCP SDK 1.29.0 already ships server.experimental.tasks.registerToolTask so we don't need to wait for the 2026-07-28 RC to start building against it.

   What's in the draft:

   • ground_location_tool now overrides installTo to use registerToolTask instead of registerTool
   • createTask returns the task handle immediately and kicks off background work without awaiting it
   • Reverse geocode and sampling classification run in parallel in the background, same as before but async -- once sampling resolves, POI search and isochrone fan out based on the strategy
   • InMemoryTaskStore wired into the server so task lifecycle is managed

   Two known gaps before this can ship: taskSupport: 'required' currently breaks clients without task support, and the in-memory store loses state on restart. Both are intentional for now since this is a design spike. The taskSupport: 'supported' fallback path should be clearer once the RC lands in July.

   One thing worth noting from the SDK branch: the valid task statuses are working, input_required, completed, failed, cancelled -- there is no running state, tasks start as working already. Tripped over that while writing the tests.
3. rehan243 commented on Jun 10, 2026

   

   rehan243

   on Jun 10, 2026

   More actions

   oh nice, didn’t realize 1.29.0 already had registerToolTask baked in — that should speed things up a lot. yeah, the taskSupport: 'required' issue is a pain; we hit that on our end too and ended up adding a fallback for legacy clients. curious if you’re planning to handle the partial support case in the next patch or workaround it for now? lmk if you want me to share our fallback snippet.
4. mattpodwysocki commented on Jun 11, 2026

   

   mattpodwysocki

   on Jun 11, 2026

   ContributorAuthor

   More actions

   yes please share it, that would be really helpful. the plan is to tackle the fallback in a follow-up once we see how the RC shapes the supported path, but having a working reference for the inline execution case would save some guesswork.
5. mattpodwysocki commented on Jun 11, 2026

   

   mattpodwysocki

   on Jun 11, 2026

   ContributorAuthor

   More actions

   went ahead and pushed the fallback in the same draft PR (#210) -- curious if this is along the lines of what you had. ended up using taskSupport: 'optional' which the SDK already handles automatically: non-task clients get the same synchronous result as before, the SDK internally creates the task, polls at 50ms intervals, and returns the result directly without the caller ever seeing a task handle.

   the relevant bit in createTask:

   const task = await extra.taskStore.createTask({
     ttl: 60_000,
     pollInterval: 50
   });
   void this.runTaskBackground(args, accessToken, task.taskId, extra.taskStore);
   return { task };

   and in runTaskBackground, sampling and the initial geocode kick off in parallel, then POI search and isochrone fan out once the strategy resolves:

   const [strategy, initialGeocode] = await Promise.all([
     this.classifyGroundingStrategy(query, longitude, latitude),
     this.reverseGeocode(longitude, latitude, accessToken, 'neighborhood,locality,place', language)
   ]);
   // refine geocode types if needed, then fan out POI + isochrone
   const [poisResult, isochroneResult] = await Promise.all([...]);
   await taskStore.storeTaskResult(taskId, 'completed', { ... });

   no custom fallback code needed since the SDK automatic polling path handles it. still keen to see what your snippet looks like though, especially if you solved the update ordering issue differently.
6. rehan243 commented on Jun 15, 2026

   

   rehan243

   on Jun 15, 2026 · Hidden as duplicate

   show commentMore actions
7. Valiunia commented on Jun 23, 2026

   

   Valiunia

   on Jun 23, 2026

   Contributor

   More actions

   closing in favour of internal ticket
8. Valiunia

   closed this as completedon Jun 23, 2026