-
Notifications
You must be signed in to change notification settings - Fork 30
Add search-along-route prompt for POI discovery along routes #105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mattpodwysocki
wants to merge
14
commits into
main
Choose a base branch
from
add-search-along-route-prompt
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Introduces a new MCP prompt that orchestrates existing tools to find places of interest along a route corridor. This enables use cases like "find Starbucks along my route from Seattle to Portland." Features: - Combines directions_tool, buffer_tool, and search tools - Configurable buffer distance (default 1km corridor) - Filters results to route corridor using point_in_polygon_tool - Orders results by distance from route - Supports all travel modes (driving, walking, cycling) Implementation: - Created SearchAlongRoutePrompt with 5 arguments (from, to, search_for, mode, buffer_meters) - Added to prompt registry - Comprehensive test coverage (28 tests passing) - Follows existing prompt patterns Example usage: "Find gas stations along the drive from LA to San Francisco" Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…rompt Creates detailed testing guide with: - 5 basic examples (coffee shops, gas stations, rest stops, restaurants, bike shops) - MCP Inspector testing instructions - Advanced examples (long routes, buffer adjustments) - Verification checklist - Common use cases Also updates README with new example prompt and reference to examples directory. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
4973bc5 to
0d44345
Compare
Addresses issue where buffer_tool fails on very long LineStrings (e.g., Seattle to Portland ~280km route). Changes: - Added explicit route length check before buffering - Provides two strategies based on route length: * Short routes (<100km): Buffer entire route at once * Long routes (≥100km): Use segmentation or point sampling - Moved segmentation guidance from "tips" to main workflow - Added specific thresholds (100km, 200 coordinate points) - Better error prevention with upfront approach selection This prevents the AI from attempting buffer operations that will fail and then falling back to suboptimal approaches like simple bounding boxes that include results far from the route. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Addresses token/complexity issues with long routes by using simpler filtering strategies based on route length. Approach: - SHORT routes (<50km): Full buffer corridor + point-in-polygon filtering * Most accurate, precise corridor results * Manageable complexity - LONG routes (≥50km): Bounding box + distance filtering * Pragmatic approach avoiding token limits * Still filters to approximate corridor * Explicitly notes to user that results are approximate Why this works: - Leesburg to Herndon (~30km): Uses precise corridor filtering - Seattle to Portland (~280km): Uses simpler bbox approach - Prevents AI from hitting token/complexity limits - Sets clear expectations with users about filtering method This is more practical than complex segmentation strategies that still overwhelm the AI on very long routes. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Fixes issue where Claude Desktop tries to use mapboxgl directly, which is not available in that environment. Changes: - Replaced generic "display a map" with explicit static_map_image_tool usage - Instructs AI to use route geometry as path overlay - Adds start/end markers and found locations - Works in Claude Desktop and other MCP clients without mapboxgl This ensures the prompt works across all MCP client environments. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Addresses token/timeout issues with very long routes (e.g., Seattle to Portland ~280km). Three-tier strategy: 1. SHORT routes (<50km): Full corridor with buffer + point-in-polygon - Most accurate, precise filtering - Example: Leesburg to Herndon 2. MEDIUM routes (50-150km): Bounding box + distance filtering - Balanced approach, filters to general corridor - Avoids full buffer complexity 3. VERY LONG routes (>150km): Strategic point sampling - Samples 5-7 evenly spaced points along route - Searches small radius (5-10km) around each point - Prevents token/timeout issues - Example: Seattle to Portland - samples major points along I-5 This approach ensures the prompt works reliably for: - Short local routes (full precision) - Regional routes (balanced filtering) - Long interstate routes (strategic sampling) Each approach explicitly informs the user which strategy was used and sets appropriate expectations about result coverage. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…ry long routes Addresses slow map encoding for routes with many coordinate points. Changes: - SHORT routes (<50km): Use simplify_tool with tolerance=0.001 before mapping * Reduces coordinates while maintaining accuracy * Shows detailed map with route, markers - MEDIUM routes (50-150km): Use simplify_tool with tolerance=0.01 * Aggressive simplification for faster encoding * Shows simplified map with fewer markers (top 5-8) - VERY LONG routes (>150km): Skip map generation entirely * Avoids slow encoding of complex 280km+ routes * Notes to user: "Map visualization skipped for route length" * Focuses on text list of results This dramatically improves performance: - Leesburg to Herndon: Fast detailed map - Seattle to Portland: No slow map encoding, instant results list The simplify_tool reduces coordinate count before static_map_image_tool, preventing the long encoding delays the user experienced. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
…ions
Addresses validation error where Claude was passing route geometry
incorrectly to bounding_box_tool, causing input schema validation failures.
Changes:
- Added explicit instructions for extracting route LineString coordinates
from directions_tool response as array of [lon, lat] pairs
- SHORT routes: Clarified buffer_tool input format and how to get bbox
from buffer polygon using bounding_box_tool
- MEDIUM routes: Added explicit bounding_box_tool usage instructions
with correct geometry format: {"geometry": [[lon1,lat1], [lon2,lat2], ...]}
- VERY LONG routes: Changed to use proximity parameter instead of bbox
to avoid coordinate extraction complexity
- Added bbox format specification for category_search_tool: "minLon,minLat,maxLon,maxLat"
This provides Claude with clear, unambiguous instructions about:
1. How to extract coordinates from directions response
2. Correct format for passing to buffer_tool and bounding_box_tool
3. How to use the resulting bbox with search tools
Fixes MCP error -32602 validation failures on Leesburg to Herndon route.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
After encountering buffer issues even on short routes (Leesburg to Herndon), this simplifies the entire workflow to use a single, reliable approach for all route lengths: sample points + proximity searches. Changes: - REMOVED: buffer_tool, bounding_box_tool, point_in_polygon_tool complexity - REMOVED: Three different strategies for different route lengths - NEW: Single unified approach - sample route points and proximity search How it works: 1. Get route with directions_tool 2. Sample points along route (density based on length): - Short routes (<50km): Every 5-10 points (comprehensive coverage) - Medium routes (50-150km): Every 15-20 points - Long routes (>150km): 5-7 strategic points 3. For each sample point, use category_search_tool with proximity parameter 4. Combine results, deduplicate, order by distance from start Why this is better: - Simple and reliable - no complex geometry operations - No buffer validation errors or "buffer result is very large" issues - No bbox calculation failures - Works consistently for ALL route lengths - Fast execution, no token/timeout issues - Proximity searches naturally cover route corridor Leesburg to Herndon: Sample every 5-10 points, comprehensive coverage Seattle to Portland: Sample 5-7 major points, fast and reliable This is the pragmatic solution that actually works in production. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
SimplifyTool expects closed polygons (first and last coordinates match) but routes are open LineStrings, causing error: "First and last Position are not equivalent" Changes: - REMOVED: simplify_tool preprocessing step entirely - Routes < 150km: Pass route geometry directly to static_map_image_tool - Routes ≥ 150km: Skip map generation to avoid slow rendering Why this works: - static_map_image_tool can handle route LineStrings without simplification - Routes are not polygons and don't need to be closed - Removing simplify_tool removes another point of failure - Keeps the workflow even simpler and more reliable This is now the absolute simplest approach: 1. Get route with directions_tool 2. Sample points and do proximity searches 3. Pass route directly to static_map_image_tool (no preprocessing) Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Addresses confusion where Claude tried to use "Starbucks" as a category
with category_search_tool, which failed because Starbucks is a brand name,
not a category. Claude self-corrected but we can avoid the initial error.
Changes:
- Added explicit guidance on choosing the right search tool:
* Specific places/brands (e.g., "Starbucks", "McDonald's")
→ Use search_and_geocode_tool
* Categories (e.g., "coffee shops", "gas stations")
→ Use category_search_tool
- Updated parameter names to match tool schemas:
* search_and_geocode_tool: q="${search_for}", proximity="lon,lat"
* category_search_tool: types="${search_for}", proximity="lon,lat"
This helps Claude make the right choice upfront, though it will still
need to use judgment. The self-correction behavior shows the AI can
recover, but this should reduce unnecessary errors.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Even short routes (Leesburg to Herndon) take a long time to encode with static_map_image_tool. Make maps optional and focus on fast text results instead. Changes: - Skip static_map_image_tool by default - Note to user: "Map visualization can be generated separately if needed" - Focus on excellent text results with all necessary data: * Route summary (distance, time) * Each result with name, address, distance from start, coordinates * Sampling strategy used - Include coordinates in results so user could map them separately - Only generate map if user explicitly requests it Why this is better: - Much faster workflow (no encoding delays) - User gets results immediately - Client apps (Claude Desktop, etc.) may have their own map capabilities - User can always request "show me a map" as a follow-up if desired - Avoids the slow static image encoding that was delaying results For Leesburg to Herndon: Results appear instantly instead of waiting for static map encoding. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
All searches at sample points are independent and can be executed concurrently, but Claude may not realize this without explicit guidance. Changes: - Added "IMPORTANT - Execute searches in parallel" section - Instructs Claude to make ALL search tool calls in a single message - Provides example: "If you have 5 sample points, make 5 search calls in one turn" - Emphasizes this dramatically speeds up the workflow Why this matters: - Sequential searches: 5 points × 2 seconds = 10 seconds - Parallel searches: 5 points in one turn = 2-3 seconds total - Especially important for medium/long routes with many sample points The agent (Claude) ultimately decides execution strategy, but explicit guidance should encourage parallel execution when possible. This is standard MCP pattern - multiple independent tool calls in one message. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Distance calculations are also independent and can be parallelized, just like the search operations. Changes: - Added explicit parallel execution guidance for distance_tool calls - Instructs Claude to make ALL distance calculations in a single message - Example: "If you have 10 unique results, make 10 distance_tool calls in one turn" Why this matters: - Sequential distance calculations: 10 results × 0.5s = 5 seconds - Parallel distance calculations: 10 results in one turn = 0.5-1s total - Further speeds up the workflow after search results are collected Complete parallel execution strategy: 1. Get route (1 call) 2. Search all sample points in parallel (N calls in one turn) 3. Calculate all distances in parallel (M calls in one turn) 4. Present results This minimizes total round-trips and execution time. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Introduces a new
search-along-routeMCP prompt that orchestrates existing tools to find places of interest along a route corridor. This enables use cases like:Motivation
With the addition of offline geospatial tools (buffer, point-in-polygon, distance), we can now compose powerful workflows. Search-along-route combines:
directions_tool- Get route geometrybuffer_tool- Create corridor around routesearch_and_geocode_tool/category_search_tool- Find POIspoint_in_polygon_tool- Filter to corridordistance_tool- Order by proximityThis showcases how offline tools enhance search workflows without requiring new API endpoints.
Implementation
New Files
src/prompts/SearchAlongRoutePrompt.ts- Prompt implementation with detailed orchestration instructionsModified Files
src/prompts/promptRegistry.ts- Register new prompttest/prompts/promptRegistry.test.ts- Test coverage for new promptPrompt Arguments
Required:
from- Starting location (address, place name, or coordinates)to- Destination location (address, place name, or coordinates)search_for- Type of place to search for (e.g., "Starbucks", "gas stations")Optional:
mode- Travel mode: driving, walking, or cycling (default: driving)buffer_meters- Search corridor width on each side of route (default: 1000m)Orchestration Steps
The prompt guides the AI through:
Example Usage
Testing
✅ All 581 tests pass
Prompt Generation
Entering the following data:
Output is the following:
Design Decisions
Why a prompt vs a tool?
Why not extend existing prompts?
Follow-up Ideas
Future enhancements could include: