Skip to main content
Glama
Sign In
immich-photo-manager

immich-photo-manager

by drolosoft
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Get map markers

get_map_markers
Read-only

Retrieve GPS map markers for geotagged photos to discover where images were taken or build travel maps, with optional date-range and favorite filters.

Instructions

Get GPS map markers for all geotagged assets. Use this to discover where photos were taken or to build travel maps. For searching by city/country name, use search_metadata instead. Read-only. Returns up to 500 markers.

Args:
    file_created_after: ISO date lower bound (e.g. '2023-01-01').
    file_created_before: ISO date upper bound.
    is_favorite: If true, only return favorites.

Returns: JSON with total count and markers array (each with asset ID, lat, lon).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_map_markers"
  }
}

Input Schema

NameRequiredDescriptionDefault
is_favoriteNo
file_created_afterNo
file_created_beforeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only' restatement adds little. However, it usefully discloses a behavioral limit ('Returns up to 500 markers') that annotations do not cover, and describes the return structure even though an output schema exists.

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 front-loaded with purpose and usage guidance, followed by a structured Args and Returns section. Some content, such as the 'Read-only' line and detailed return shape, repeats annotations or the output schema, but it remains readable and largely earns its place.

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 simple read-only tool with three optional parameters, the description covers purpose, alternatives, behavioral limits, parameter formats, and return contents. Nothing essential for correct invocation is missing.

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?

Schema description coverage is 0%, so the description carries the full burden. It documents all three parameters with concrete semantics: ISO date examples for file_created_after and file_created_before, and the meaning of is_favorite as filtering to favorites only.

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?

States a specific verb and resource ('Get GPS map markers for all geotagged assets') and distinguishes the tool from search_metadata by naming the city/country alternative. An agent can immediately tell this is for coordinate-based discovery rather than metadata search.

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

Usage Guidelines5/5

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

Explicitly gives use cases ('discover where photos were taken or to build travel maps') and names the alternative tool ('search_metadata') for city/country searching. The when-to-use versus when-not-to-use guidance is clear and actionable.

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

Deploy Server

Other Tools