Skip to main content
Glama
deenesjakoruzh
vlad-ds

Street View MCP

by vlad-ds
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Street View MCP

A Model-Client-Protocol (MCP) server for Google Street View API that enables AI models to fetch and display street view imagery and create virtual tours.

Using with Claude Desktop

To use Street View MCP with Claude Desktop:

  1. Ensure you have uv installed: UV Installation Guide

  2. Clone this repository:

    git clone https://github.com/vlad-ds/street-view-mcp.git
cd street-view-mcp

  3. Install dependencies:

    uv pip install -e ".[dev]"

  4. Get a Google Maps API key (instructions below)

  5. Add the following to your Claude Desktop claude_desktop_config.json file:

"street_view": {
  "command": "uv",
  "args": [
    "run",
    "--directory",
    "/path/to/street-view-mcp",  // Replace with your actual path
    "mcp",
    "run",
    "src/street_view_mcp/server.py"
  ],
  "env": {
    "API_KEY": "your_google_maps_api_key_here"  // Add your API key here
  }
}

After configuration, you can use Street View MCP in Claude Desktop simply by typing "/street_view".

Related MCP server: MCP Google Map Server

Overview

Street View MCP provides a simple interface for AI models to:

  1. Fetch Street View images by address, coordinates, or panorama ID

  2. Save images to local files

  3. Open saved images in the default viewer

  4. Create HTML pages that compile multiple Street View images into virtual tours

Requirements

  • Python 3.9+

  • Google Maps API key with Street View API enabled

  • fastmcp package

  • uv package manager (recommended)

Installation

# Clone the repository
git clone https://github.com/vlad-ds/street-view-mcp.git
cd street-view-mcp

# Create and activate a virtual environment with uv (recommended)
uv venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate

# Install dependencies
uv pip install -e ".[dev]"

API Key Setup

The Street View MCP requires a Google Maps API key with Street View API enabled:

  1. Visit the Google Cloud Console

  2. Create a new project or select an existing one

  3. Enable the "Street View Static API" in the API Library

  4. Create an API key from the Credentials page

  5. Set the API key as an environment variable:

# Set temporarily in your shell:
export API_KEY=your_api_key_here

# Or create a .env file in the project root:
echo "API_KEY=your_api_key_here" > .env

Usage

Starting the MCP Server

python -m street_view_mcp.main --host 127.0.0.1 --port 8000

The server will be available to AI models at the specified host and port.

Using as a CLI Tool

# Fetch Street View image by address
python -m street_view_mcp.street_view --address "Empire State Building, NY" --output output/empire_state.jpg

# Fetch Street View image by latitude/longitude
python -m street_view_mcp.street_view --latlong "40.748817,-73.985428" --output output/coords.jpg --heading 180

# Fetch Street View image by panorama ID
python -m street_view_mcp.street_view --pano PANO_ID --output output/panorama.jpg

MCP Tools

The Street View MCP provides the following tools for AI models:

get_street_view

Fetches a Street View image based on location, coordinates, or panorama ID and saves it to a file.

{
  "filename": "empire_state.jpg",
  "location": "Empire State Building, NY",
  "size": "600x400",
  "heading": 90,
  "pitch": 10
}

Parameters:

  • filename (required): Name for saving the image (must not already exist)

  • location (optional): Address to get image for

  • lat_lng (optional): Comma-separated coordinates (e.g., "40.748817,-73.985428")

  • pano_id (optional): Specific panorama ID

  • size (optional): Image dimensions as "widthxheight" (default: "600x400")

  • heading (optional): Camera heading in degrees (0-360, default: 0)

  • pitch (optional): Camera pitch in degrees (-90 to 90, default: 0)

  • fov (optional): Field of view in degrees (10-120, default: 90)

  • radius (optional): Search radius in meters (default: 50)

  • source (optional): Image source ("default" or "outdoor", default: "default")

Note: Exactly one of location, lat_lng, or pano_id must be provided.

get_metadata

Fetches metadata about a Street View panorama.

{
  "location": "Empire State Building, NY"
}

Parameters:

  • Same location parameters as get_street_view

  • Returns JSON metadata with status, copyright, date, panorama ID, and coordinates

open_image_locally

Opens a saved Street View image in the default application.

{
  "filename": "empire_state.jpg"
}

Parameters:

  • filename (required): The filename of the image to open (must exist in output directory)

create_html_page

Creates an HTML page that displays multiple Street View images as a virtual tour.

{
  "filename": "nyc_tour.html",
  "title": "New York City Tour",
  "html_elements": [
    "<h1>New York City Landmarks Tour</h1>",
    "<p>Explore famous landmarks through Street View images.</p>",
    "<h2>Empire State Building</h2>",
    "<img src='../output/empire.jpg' alt='Empire State Building'>",
    "<p class='location'>350 Fifth Avenue, New York, NY</p>",
    "<p class='description'>This 102-story Art Deco skyscraper was completed in 1931.</p>"
  ]
}

Parameters:

  • html_elements (required): List of HTML content elements

  • filename (required): Name for the HTML file

  • title (optional): Page title (default: "Street View Tour")

Important: When referencing images, always use the path ../output/filename.jpg.

Creating Virtual Tours

The Street View MCP enables creation of virtual tours by combining multiple Street View images with descriptive text in an HTML page.

Example workflow for creating a tour:

  1. Fetch images of different locations:

get_street_view(filename="empire.jpg", location="Empire State Building, NY")
get_street_view(filename="times_square.jpg", location="Times Square, NY")
get_street_view(filename="central_park.jpg", location="Central Park, NY")

  1. Create an HTML tour page:

create_html_page(
  filename="nyc_tour.html",
  title="New York City Tour",
  html_elements=[
    "<h1>New York City Landmarks Tour</h1>",
    "<p>Explore these famous NYC landmarks through Street View images.</p>",
    
    "<h2>Empire State Building</h2>",
    "<img src='../output/empire.jpg' alt='Empire State Building'>",
    "<p class='location'>350 Fifth Avenue, New York, NY</p>",
    "<p class='description'>An iconic 102-story Art Deco skyscraper in Midtown Manhattan.</p>",
    
    "<h2>Times Square</h2>",
    "<img src='../output/times_square.jpg' alt='Times Square'>",
    "<p class='location'>Broadway & 7th Avenue, New York, NY</p>",
    "<p class='description'>Famous for its bright lights, Broadway theaters, and as the site of the annual New Year's Eve ball drop.</p>",
    
    "<h2>Central Park</h2>",
    "<img src='../output/central_park.jpg' alt='Central Park'>",
    "<p class='location'>Central Park, New York, NY</p>",
    "<p class='description'>An urban park spanning 843 acres in the heart of Manhattan.</p>"
  ]
)

Project Structure

  • street_view_mcp/

    • __init__.py: Package initialization

    • main.py: Entry point for MCP server

    • server.py: MCP server implementation

    • street_view.py: Core Street View API client

Important Notes

  • Local Storage: This tool saves all Street View images and HTML files locally in the output/ directory

  • No Automatic Cleanup: There is no built-in mechanism to delete saved files

  • Manual Cleanup: You should periodically clean up the output/ directory to manage disk space

  • API Usage: Each image request counts toward your Google Maps API quota and may incur charges

Development

Testing

pytest

License

MIT

Available Tools

4 tools
create_html_pageA

Create an HTML page specifically for displaying Street View images with descriptive text.

This tool is designed to compile multiple Street View images into a single viewable HTML document, creating a virtual tour or location showcase. The function automatically wraps your content in a complete HTML document with:

  • DOCTYPE declaration

  • HTML, head, and body tags

  • Basic responsive styling optimized for displaying images

  • Title from the parameter

Args: html_elements: List of content HTML elements (just the body content, no need for HTML structure) filename: Name of the HTML file to create (without directory path) title: Title for the HTML page

Returns: Dict: A status message indicating success or failure

Raises: ValueError: If the filename already exists or is invalid

Note: - You only need to provide the CONTENT elements (no need for html, head, body tags) - IMPORTANT: When including Street View images, you MUST use the path "../output/": <img src="../output/empire.jpg" alt="Empire State Building"> - The "../" prefix is REQUIRED because HTML files are in html/ directory while images are in output/ directory (both at the same level)

Example usage: ``` # Create a virtual Street View tour with multiple locations html_elements = [ "New York City Landmarks Tour", "Explore famous landmarks through Street View images.",

    "<h2>Empire State Building</h2>",
    "<img src='../output/empire.jpg' alt='Empire State Building'>",
    "<p class='location'>350 Fifth Avenue, New York, NY</p>",
    "<p class='description'>This 102-story Art Deco skyscraper in Midtown Manhattan was completed in 1931.</p>",
    
    "<h2>Times Square</h2>",
    "<img src='../output/timessquare.jpg' alt='Times Square'>",
    "<p class='location'>Broadway & 7th Avenue, New York, NY</p>", 
    "<p class='description'>Famous for its bright lights, Broadway theaters, and as the site of the annual New Year's Eve ball drop.</p>"
]
```

HTML Boilerplate (automatically added): <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>{title}</title> <style> body { font-family: Arial, sans-serif; line-height: 1.6; max-width: 800px; margin: 0 auto; padding: 20px; color: #333; } img { max-width: 100%; height: auto; border-radius: 5px; margin: 20px 0; } h1, h2, h3 { color: #2c3e50; } </style> </head> <body> <!-- Your content elements are inserted here --> </body> </html>

ParametersJSON Schema
NameRequiredDescriptionDefault
html_elementsYes
filenameYes
titleNoStreet View Tour

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits. It explains what gets created (complete HTML document with specific structure), includes important constraints (filename validation, path requirements for images), and describes error conditions (ValueError for existing/invalid filenames). It also shows the complete boilerplate that will be automatically added.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is comprehensive but could be more front-loaded. While all information is valuable, the detailed example and boilerplate sections make it quite lengthy. The core information is presented early, but the overall structure includes multiple sections that could potentially be streamlined.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no annotations and no output schema, the description provides exceptional completeness. It covers purpose, usage, parameters, constraints, examples, and even shows the exact HTML structure that will be generated. The return value is clearly explained ('Dict: A status message indicating success or failure'), and error conditions are documented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description fully compensates by providing detailed parameter explanations. It clarifies that html_elements should be 'just the body content, no need for HTML structure,' specifies filename format 'without directory path,' and explains the title parameter's role. The example usage provides concrete parameter values and formatting guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Create an HTML page specifically for displaying Street View images with descriptive text.' It specifies the verb ('create'), resource ('HTML page'), and distinguishes from siblings by focusing on Street View image compilation rather than metadata retrieval or image viewing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for compiling multiple Street View images into a viewable HTML document for virtual tours or showcases. It doesn't explicitly state when not to use it or name alternatives among siblings, but the specific use case is well-defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_metadataB

Fetch metadata about a Street View panorama.

Args: location: The address to check for Street View imagery lat_lng: Comma-separated latitude and longitude (e.g., "40.748817,-73.985428") pano_id: Specific panorama ID to fetch metadata for radius: Search radius in meters when using location or coordinates source: Limit Street View searches to selected sources ("default" or "outdoor")

Returns: Dict: Panorama metadata including status, copyright, date, pano_id, lat, lng

ParametersJSON Schema
NameRequiredDescriptionDefault
locationNo
lat_lngNo
pano_idNo
radiusNo
sourceNodefault

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a 'fetch' operation but doesn't clarify whether it's read-only, requires authentication, has rate limits, or what happens with invalid inputs. The description mentions what the tool returns but lacks behavioral context about error handling, performance, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose statement, Args, Returns) and efficiently conveys necessary information. The purpose statement is front-loaded, and each parameter explanation earns its place. Minor verbosity in the Returns section could be tightened, but overall it's appropriately sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no annotations and no output schema, the description provides adequate coverage of parameters and return values. However, it lacks important contextual information about authentication requirements, error conditions, rate limits, and how it differs from sibling tools. The return format description is helpful but could be more detailed given the absence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining all 5 parameters in the Args section. It provides meaningful context about what each parameter does (e.g., 'Search radius in meters when using location or coordinates'), including examples and default values. This adds substantial value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Fetch metadata about a Street View panorama.' It specifies the verb ('fetch') and resource ('metadata about a Street View panorama'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_street_view' (which likely retrieves the actual imagery rather than metadata).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_street_view' or explain scenarios where metadata fetching is preferred over retrieving the actual Street View image. The parameter descriptions imply usage contexts but don't offer explicit when-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_street_viewA

Fetch a Street View image based on location, coordinates, or panorama ID and save to file.

Args: filename: Required filename to save the image (must not already exist in output directory) location: The address to get Street View image for (e.g., "Empire State Building, NY") lat_lng: Comma-separated latitude and longitude (e.g., "40.748817,-73.985428") pano_id: Specific panorama ID to fetch size: Image dimensions as "widthxheight" (e.g., "600x400") heading: Camera heading in degrees (0-360) pitch: Camera pitch in degrees (-90 to 90) fov: Field of view in degrees (zoom level, 10-120) radius: Search radius in meters when using location or coordinates source: Limit Street View searches to selected sources ("default" or "outdoor")

Returns: Image: The Street View image

Raises: ValueError: If filename already exists in output directory

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
locationNo
lat_lngNo
pano_idNo
sizeNo600x400
headingNo
pitchNo
fovNo
radiusNo
sourceNodefault

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does well by disclosing key behaviors: it saves to a file, requires a unique filename, and raises a ValueError for duplicates. It also hints at search functionality with 'radius' and 'source' parameters, though it doesn't cover rate limits or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence, organized parameter list, and return/error sections. It's appropriately sized for a 10-parameter tool, though some redundancy exists (e.g., repeating 'degrees' for heading/pitch).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with 10 parameters, no annotations, and no output schema, the description is largely complete, covering purpose, parameters, returns, and errors. However, it lacks details on output format beyond 'Image' and doesn't address potential network or API limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Given 0% schema description coverage, the description fully compensates by providing detailed semantics for all 10 parameters, including examples, constraints (e.g., '0-360' for heading), and defaults where applicable, adding significant value beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('fetch', 'save to file') and resources ('Street View image'), and distinguishes it from sibling tools like 'get_metadata' or 'open_image_locally' by emphasizing image retrieval and file saving.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage through parameter explanations (e.g., location vs. lat_lng vs. pano_id) but lacks explicit guidance on when to use this tool versus alternatives like 'get_metadata' or 'open_image_locally'. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_image_locallyB

Open a saved Street View image in the default application.

Args: filename: The filename of the image to open (must exist in output directory)

Returns: Dict: A status message indicating success or failure

Raises: ValueError: If the file doesn't exist in the output directory

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes

TDQS

B3.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool opens files in the default application (implying a system-level action) and raises errors for non-existent files, which is useful behavioral context. However, it lacks details on permissions needed, platform-specific behavior, or what 'success' entails beyond a status message.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence followed by Args/Returns/Raises sections. It's appropriately sized for a simple tool, though the 'Dict' return type could be more specific. Every sentence adds value, but the structure is slightly verbose for a single-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one parameter and no output schema, the description covers the basic operation and error case adequately. However, it lacks context about the output directory (where files are saved) and doesn't explain the return value format beyond 'Dict', leaving gaps for the agent to understand the full workflow.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, but the description compensates well by explaining the 'filename' parameter's purpose ('The filename of the image to open') and constraint ('must exist in output directory'). This adds crucial meaning beyond the bare schema, though it doesn't specify the output directory location or file format expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Open') and resource ('saved Street View image') with specific context ('in the default application'). It distinguishes from siblings like 'get_street_view' (which likely fetches images) by focusing on opening existing files. However, it doesn't explicitly contrast with 'create_html_page' or 'get_metadata'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., that the file must already exist from another operation) or compare with sibling tools like 'get_street_view' for obtaining images. The only implicit context is the file existence requirement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 4 tool updates
    • First observedcreate_html_page
    • First observedget_metadata
    • First observedget_street_view
    • First observedopen_image_locally
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a distinct, non-overlapping purpose: get_metadata retrieves panorama data, get_street_view fetches and saves images, create_html_page compiles images into HTML documents, and open_image_locally opens saved images. The boundaries are clear with no ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern: get_metadata, get_street_view, create_html_page, open_image_locally. The naming is uniform and predictable, using clear action verbs followed by descriptive nouns.

Tool Count5/5

With 4 tools, this server is well-scoped for Street View functionality. Each tool serves a specific, necessary role in the workflow: metadata retrieval, image acquisition, HTML compilation, and local viewing. No tool feels redundant or missing for the domain.

Completeness4/5

The toolset covers the core Street View workflow comprehensively: fetching metadata, acquiring images, creating HTML tours, and viewing images locally. A minor gap exists in lacking direct image manipulation or advanced HTML customization tools, but the basic lifecycle is fully covered without dead ends.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Google Map Server

    cablate
    A
    license
    B
    quality
    A
    maintenance
    A Model Context Protocol server that provides Google Maps API integration, allowing users to search locations, get place details, geocode addresses, calculate distances, obtain directions, and retrieve elevation data through LLM processing capabilities.
    7
    863
    441
    MIT

  • Restaurant Booking MCP Server

    samwang0723
    A
    license
    A
    quality
    F
    maintenance
    An AI-powered server that helps users discover and book restaurants based on location, cuisine preferences, mood, and event type, with integration to Google Maps Places API for accurate recommendations.
    5
    16
    MIT

  • Cloudflare Playwright MCP

    sent3nal
    F
    license
    Not graded
    quality
    C
    maintenance
    A server that enables AI assistants to control a browser through tools, allowing them to perform web automation tasks like navigation, typing, clicking, and taking screenshots.
    -

Appeared in Searches

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vlad-ds/street-view-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server