photos-mcp

Photos List

photos_list

Read-onlyIdempotent

List photos and videos from a Google Photos library by source, date range, and media type, with cursor pagination and optional location/camera details.

Instructions

List the library newest-first by taken date (archive excluded; from_date/to_date for an exact range of the items' own local dates), the archive, one album, the favourites, or what was uploaded most recently. Same item shape as photos_search; place is set where Google's listing carries it (details=true adds it, with lat, lon and camera).

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

Input Schema

Name	Required	Description	Default
`limit`	No	Items per page (1-50)
`media`	No	Only photos, only videos, or all (default)	all
`cursor`	No	next_cursor from the previous page
`source`	No	library (default), archive, album, favourites, recently_added (newest upload first), or trash (most recently deleted first)	library
`details`	No	Also lat, lon and camera per item, and place where missing (limit up to 20; one more request)
`to_date`	No	library/archive: taken on or before this date
`album_id`	No	Album id; required iff source=album
`from_date`	No	library/archive: taken on or after this date

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.11.3Oct 27, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already cover the read-only/idempotent safety profile, and the description adds real behavioral context beyond them: default newest-first ordering, archive exclusion, that date filters are on items' own local dates, and that details=true costs one more request and caps limit at 20. Only pagination/return-shape behavior is unaddressed, and an output schema covers that.

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?

Front-loaded with the core action and default ordering, and every clause carries information. It is a single dense sentence with stacked parentheticals, which is efficient but slightly harder to parse than short separate clauses.

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?

With 8 params fully documented in the schema and an output schema present, the description fills the remaining gaps that matter: default source behavior, ordering, date semantics, and the details cost/cap. Missing only explicit alternative-tool routing, which is a usage gap rather than a completeness one.

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?

Schema coverage is 100%, so baseline is 3, but the description adds meaning not in the schema: date bounds refer to the items' own local dates and 'exact range' semantics, and it clarifies that place metadata only appears where Google's listing carries it. This is incremental value on top of already-complete parameter docs.

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?

States a specific verb and resource with scope: lists the library newest-first by taken date, plus archive, album, favourites, or recently uploaded, and notes the item shape matches photos_search. It does not explicitly say how it differs functionally from photos_search or photos_view, so it falls short of full sibling differentiation.

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?

Usage is implied through the enumerated sources and the 'from_date/to_date for an exact range' note, and 'archive excluded' signals the default scope. But there is no explicit when-to-use-this-vs-photos_search guidance despite photos_search being the closest sibling, leaving the agent to infer the routing.

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

Deploy Server