Skip to main content
Glama
deenesjakoruzh
vlad-ds

Street View MCP

by vlad-ds
OverviewSchemaSourceRelated ServersScoreDiscussions
Python
Hybrid

Vista de calle MCP

Un servidor de protocolo modelo-cliente (MCP) para la API de Google Street View que permite que los modelos de IA obtengan y muestren imágenes de vistas de calles y creen recorridos virtuales.

Uso con Claude Desktop

Para utilizar Street View MCP con Claude Desktop:

  1. Asegúrese de tener instalado uv : Guía de instalación de UV

  2. Clonar este repositorio:

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

  3. Instalar dependencias:

    uv pip install -e ".[dev]"

  4. Obtenga una clave API de Google Maps (instrucciones a continuación)

  5. Agregue lo siguiente a su archivo claude_desktop_config.json de Claude Desktop:

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

Después de la configuración, puedes usar Street View MCP en Claude Desktop simplemente escribiendo "/street_view".

Related MCP server: MCP Google Map Server

Descripción general

Street View MCP proporciona una interfaz sencilla para que los modelos de IA puedan:

  1. Obtener imágenes de Street View por dirección, coordenadas o ID de panorama

  2. Guardar imágenes en archivos locales

  3. Abrir imágenes guardadas en el visor predeterminado

  4. Cree páginas HTML que compilen múltiples imágenes de Street View en recorridos virtuales

Requisitos

  • Python 3.9+

  • Clave API de Google Maps con API de Street View habilitada

  • paquete fastmcp

  • gestor de paquetes uv (recomendado)

Instalación

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

Configuración de la clave API

El MCP de Street View requiere una clave API de Google Maps con la API de Street View habilitada:

  1. Visita la consola de Google Cloud

  2. Crea un nuevo proyecto o selecciona uno existente

  3. Habilite la "API estática de Street View" en la biblioteca de API

  4. Cree una clave API desde la página Credenciales

  5. Establezca la clave API como una variable de entorno:

# 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

Uso

Iniciando el servidor MCP

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

El servidor estará disponible para los modelos de IA en el host y puerto especificados.

Uso como herramienta 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

Herramientas MCP

El MCP de Street View proporciona las siguientes herramientas para modelos de IA:

get_street_view

Obtiene una imagen de Street View según la ubicación, las coordenadas o el ID del panorama y la guarda en un archivo.

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

Parámetros:

  • filename (obligatorio): nombre para guardar la imagen (no debe existir ya)

  • location (opcional): Dirección para obtener la imagen

  • lat_lng (opcional): coordenadas separadas por comas (p. ej., "40.748817,-73.985428")

  • pano_id (opcional): ID de panorama específico

  • size (opcional): Dimensiones de la imagen como "ancho x alto" (predeterminado: "600x400")

  • heading (opcional): rumbo de la cámara en grados (0-360, predeterminado: 0)

  • pitch (opcional): Inclinación de la cámara en grados (-90 a 90, predeterminado: 0)

  • fov (opcional): Campo de visión en grados (10-120, predeterminado: 90)

  • radius (opcional): radio de búsqueda en metros (predeterminado: 50)

  • source (opcional): Fuente de la imagen ("predeterminada" o "exterior", predeterminada: "predeterminada")

Nota: Se debe proporcionar exactamente uno de los valores: location , lat_lng o pano_id .

get_metadata

Obtiene metadatos sobre un panorama de Street View.

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

Parámetros:

  • Los mismos parámetros de ubicación que get_street_view

  • Devuelve metadatos JSON con estado, derechos de autor, fecha, ID de panorama y coordenadas

open_image_locally

Abre una imagen de Street View guardada en la aplicación predeterminada.

{
  "filename": "empire_state.jpg"
}

Parámetros:

  • filename (obligatorio): el nombre del archivo de la imagen a abrir (debe existir en el directorio de salida)

create_html_page

Crea una página HTML que muestra múltiples imágenes de Street View como un recorrido virtual.

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

Parámetros:

  • html_elements (obligatorio): Lista de elementos de contenido HTML

  • filename (obligatorio): nombre del archivo HTML

  • title (opcional): Título de la página (predeterminado: "Recorrido por Street View")

Importante: Al referenciar imágenes, utilice siempre la ruta ../output/filename.jpg .

Creación de recorridos virtuales

El MCP de Street View permite la creación de recorridos virtuales combinando múltiples imágenes de Street View con texto descriptivo en una página HTML.

Ejemplo de flujo de trabajo para crear un recorrido:

  1. Obtener imágenes de diferentes ubicaciones:

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. Crear una página de recorrido 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>"
  ]
)

Estructura del proyecto

  • street_view_mcp/

    • __init__.py : Inicialización del paquete

    • main.py : Punto de entrada para el servidor MCP

    • server.py : implementación del servidor MCP

    • street_view.py : Cliente de la API principal de Street View

Notas importantes

  • Almacenamiento local : esta herramienta guarda todas las imágenes de Street View y los archivos HTML localmente en el directorio output/

  • Sin limpieza automática : no hay un mecanismo integrado para eliminar archivos guardados

  • Limpieza manual : debe limpiar periódicamente el directorio output/ para administrar el espacio en disco

  • Uso de API : cada solicitud de imagen cuenta para su cuota de API de Google Maps y puede generar cargos.

Desarrollo

Pruebas

pytest

Licencia

Instituto Tecnológico de Massachusetts (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