Skip to main content
Glama

Look at a photo

get_photo
Read-only

View an item's photo by attachment ID to inspect its condition, labels, serial plates, or a document's first page; choose small for recognition or large to read small print.

Instructions

Shows you one of an item's photos as an image, so you can see the thing itself — its condition, a label or serial plate, which one it is — rather than only what the vision model wrote about it in get_item. The attachment's id comes from get_item's attachments; for a document (a PDF) you get a picture of its first page. size small (the default) is a 600-pixel copy, enough to recognise things; large is up to 1568 pixels, for reading small print. Changes nothing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idYesThe photo's or document's id, from get_item's attachments
sizeNosmall: a 600-pixel copy; large: up to 1568 pixels, for small printsmall

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2026.11.6

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so "Changes nothing" is largely redundant, but the description goes beyond them by disclosing that a PDF yields an image of its first page and that size controls a 600px vs up-to-1568px copy. Those are real behavioral facts an agent can't get from the annotations. Cost, latency, or failure modes for missing/invalid ids are not covered.

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?

Four tight sentences, front-loaded with the core purpose and then the id source, format edge case, and size tradeoff. Every sentence carries information; the only slack is "Changes nothing," which duplicates the readOnly annotation.

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?

With no output schema, the description takes on the burden of saying what you receive, and it does: an image of the attachment, or the first page for a PDF, at a stated resolution. For a two-parameter read tool with full annotation coverage, nothing an agent needs to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented, and the description mostly restates them (600px default vs 1568px for small print, id from attachments). The one small addition is the intent behind small ("enough to recognise things"), which is marginal. Baseline 3 applies when the schema does the heavy lifting.

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?

"Shows you one of an item's photos as an image" gives a specific verb and resource, and immediately contrasts it with get_item's textual vision-model output, so an agent can distinguish this from the sibling that returns descriptions rather than pixels. It also names the domain object (an item's attachment) and the document case, leaving no ambiguity about what comes back.

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?

It explains the selecting condition well: use this when you need to see condition, a label or serial plate, or which copy it is, rather than trusting the written description from get_item. The id provenance (get_item's attachments) is stated, which answers the main 'where do I get the argument' question. There's no explicit when-not or exclusion, so it stops short of the top mark.

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