Skip to main content
Glama
deenesjakoruzh
vlad-ds

Street View MCP

by vlad-ds
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Hybrid

스트리트 뷰 MCP

AI 모델이 스트리트 뷰 이미지를 가져와 표시하고 가상 투어를 생성할 수 있도록 하는 Google Street View API용 MCP(모델-클라이언트-프로토콜) 서버입니다.

Claude Desktop과 함께 사용

Claude Desktop에서 Street View MCP를 사용하려면:

  1. uv 설치되어 있는지 확인하세요: UV 설치 가이드

  2. 이 저장소를 복제하세요:

    지엑스피1

  3. 종속성 설치:

    uv pip install -e ".[dev]"

  4. Google Maps API 키 받기(아래 지침 참조)

  5. Claude Desktop claude_desktop_config.json 파일에 다음을 추가하세요.

"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
  }
}

구성 후, Claude Desktop에서 "/street_view"를 입력하기만 하면 Street View MCP를 사용할 수 있습니다.

Related MCP server: MCP Google Map Server

개요

Street View MCP는 AI 모델에 다음과 같은 간단한 인터페이스를 제공합니다.

  1. 주소, 좌표 또는 파노라마 ID로 스트리트 뷰 이미지 가져오기

  2. 로컬 파일에 이미지 저장

  3. 기본 뷰어에서 저장된 이미지 열기

  4. 여러 개의 Street View 이미지를 가상 투어로 컴파일하는 HTML 페이지를 만듭니다.

요구 사항

  • 파이썬 3.9 이상

  • Street View API가 활성화된 Google Maps API 키

  • fastmcp 패키지

  • uv 패키지 관리자(추천)

설치

# 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 키 설정

Street View MCP에는 Street View API가 활성화된 Google Maps API 키가 필요합니다.

  1. Google Cloud Console을 방문하세요

  2. 새 프로젝트를 만들거나 기존 프로젝트를 선택하세요

  3. API 라이브러리에서 "Street View Static API"를 활성화하세요.

  4. 자격 증명 페이지에서 API 키를 만듭니다.

  5. API 키를 환경 변수로 설정합니다.

# 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

용법

MCP 서버 시작

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

AI 모델은 지정된 호스트와 포트에서 서버를 사용할 수 있습니다.

CLI 도구로 사용

# 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 도구

Street View MCP는 AI 모델에 대해 다음과 같은 도구를 제공합니다.

get_street_view

위치, 좌표 또는 파노라마 ID를 기반으로 스트리트 뷰 이미지를 가져와 파일에 저장합니다.

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

매개변수:

  • filename (필수): 이미지를 저장할 이름(이미 존재하면 안 됨)

  • location (선택 사항): 이미지를 가져올 주소

  • lat_lng (선택 사항): 쉼표로 구분된 좌표(예: "40.748817,-73.985428")

  • pano_id (선택 사항): 특정 파노라마 ID

  • size (선택 사항): 이미지 크기는 "너비x높이"입니다(기본값: "600x400")

  • heading (선택 사항): 카메라 방향(도 단위, 0~360, 기본값: 0)

  • pitch (선택 사항): 카메라 피치(-90~90도, 기본값: 0)

  • fov (선택 사항): 시야각(도 단위, 10~120, 기본값: 90)

  • radius (선택 사항): 검색 반경(미터)(기본값: 50)

  • source (선택 사항): 이미지 출처("기본값" 또는 "실외", 기본값: "기본값")

참고: location , lat_lng 또는 pano_id 중 하나만 제공해야 합니다.

get_metadata

스트리트 뷰 파노라마에 대한 메타데이터를 가져옵니다.

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

매개변수:

  • get_street_view 와 동일한 위치 매개변수

  • 상태, 저작권, 날짜, 파노라마 ID 및 좌표가 포함된 JSON 메타데이터를 반환합니다.

open_image_locally

기본 애플리케이션에서 저장된 Street View 이미지를 엽니다.

{
  "filename": "empire_state.jpg"
}

매개변수:

  • filename (필수): 열려는 이미지의 파일 이름(출력 디렉토리에 있어야 함)

create_html_page

여러 개의 스트리트 뷰 이미지를 가상 투어로 표시하는 HTML 페이지를 만듭니다.

{
  "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>"
  ]
}

매개변수:

  • html_elements (필수): HTML 콘텐츠 요소 목록

  • filename (필수): HTML 파일의 이름

  • title (선택 사항): 페이지 제목(기본값: "스트리트 뷰 투어")

중요: 이미지를 참조할 때는 항상 ../output/filename.jpg 경로를 사용하세요.

가상 투어 만들기

Street View MCP를 사용하면 HTML 페이지에서 여러 개의 Street View 이미지와 설명 텍스트를 결합하여 가상 투어를 만들 수 있습니다.

투어 생성을 위한 워크플로 예시:

  1. 다양한 위치의 이미지 가져오기:

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. HTML 투어 페이지를 만드세요.

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>"
  ]
)

프로젝트 구조

  • street_view_mcp/

    • __init__.py : 패키지 초기화

    • main.py : MCP 서버의 진입점

    • server.py : MCP 서버 구현

    • street_view.py : 핵심 스트리트 뷰 API 클라이언트

중요 참고 사항

  • 로컬 저장소 : 이 도구는 모든 Street View 이미지와 HTML 파일을 output/ 디렉토리에 로컬로 저장합니다.

  • 자동 정리 없음 : 저장된 파일을 삭제하는 내장 메커니즘이 없습니다.

  • 수동 정리 : 디스크 공간을 관리하려면 주기적으로 output/ 디렉토리를 정리해야 합니다.

  • API 사용 : 각 이미지 요청은 Google Maps API 할당량에 포함되며 요금이 부과될 수 있습니다.

개발

테스트

pytest

특허

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
ResponsivenessNo issues

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