Skip to main content
Glama

Show property or room photos

show_property_photos
Read-onlyIdempotent

Default visual presentation for a focused property or room discussion when photos help, UI is supported and text-only was not requested. Render once; reuse the same returned room identity for explicit retries. Read only: show a PROPERTY-only or ROOM-only gallery of actual published photos. Default ROOM when roomId/roomQuery is supplied, PROPERTY otherwise. A room never includes property photos. Use exact room IDs from availability or a unique room name; no substitutions. Pages contain at most12 photos. No dates required. get_photo_gallery is data-only for in-card pagination; show_property_photos intentionally renders once.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoPROPERTY only or ROOM only. Omit to infer ROOM when a room is supplied, PROPERTY otherwise.
offsetNo
roomIdNoExact roomId from availability; must belong to this property.
roomQueryNo
propertyTokenYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewYes
totalYes
offsetYes
photosYes
roomIdYes
messageYes
versionYes
roomNameYes
roomMatchYes
nextOffsetYes
propertyNameYes
propertyTokenYes
previousOffsetYes
mediaPropertyIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed20 schema fields changed
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "maximum": 100000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / roomId
      Added value: +{
      +  "description": "Exact roomId from availability; must belong to this property.",
      +  "maxLength": 160,
      +  "minLength": 1,
      +  "type": "string"
      +}
    • addedInput schema / properties / view
      Added value: +{
      +  "description": "PROPERTY only or ROOM only. Omit to infer ROOM when a room is supplied, PROPERTY otherwise.",
      +  "enum": [
      +    "PROPERTY",
      +    "ROOM"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / nextOffset
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / offset
      Added value: +{
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedOutput schema / properties / photos / items / properties / id
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / photos / items / properties / status / const
      Added value: +"PUBLISHED"
    • removedOutput schema / properties / photos / items / properties / status / enum
      Removed value: -[
      -  "PUBLISHED",
      -  "UNAVAILABLE"
      -]
    • removedOutput schema / properties / photos / items / properties / url / anyOf
      Removed value: -[
      -  {
      -    "format": "uri",
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / photos / items / properties / url / format
      Added value: +"uri"
    • addedOutput schema / properties / photos / items / properties / url / type
      Added value: +"string"
    • changedOutput schema / properties / photos / items / required
      Previous value: -[
      -  "subject",
      -  "caption",
      -  "status",
      -  "url"
      -]New value: +[
      +  "id",
      +  "subject",
      +  "caption",
      +  "status",
      +  "url"
      +]
    • changedOutput schema / properties / photos / maxItems
      Previous value: -2New value: +12
    • removedOutput schema / properties / photos / minItems
      Removed value: -2
    • addedOutput schema / properties / previousOffset
      Added value: +{
      +  "anyOf": [
      +    {
      +      "maximum": 9007199254740991,
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / roomId
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / total
      Added value: +{
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • changedOutput schema / properties / version / const
      Previous value: -1New value: +2
    • addedOutput schema / properties / view
      Added value: +{
      +  "enum": [
      +    "PROPERTY",
      +    "ROOM"
      +  ],
      +  "type": "string"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "version",
      -  "propertyToken",
      -  "propertyName",
      -  "mediaPropertyId",
      -  "roomName",
      -  "roomMatch",
      -  "message",
      -  "photos"
      -]New value: +[
      +  "version",
      +  "view",
      +  "propertyToken",
      +  "propertyName",
      +  "mediaPropertyId",
      +  "roomId",
      +  "roomName",
      +  "roomMatch",
      +  "message",
      +  "offset",
      +  "total",
      +  "previousOffset",
      +  "nextOffset",
      +  "photos"
      +]
  2. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description reinforces this with 'Read only'. It adds real behavioral context beyond the annotations: render once, reuse the same returned room identity for explicit retries, pages capped at 12 photos, no dates required, and that a room gallery never includes property photos.

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?

Dense and front-loaded, with the routing/default logic and the render-once constraint stated up front. Slightly jargon-heavy ('explicit retries', 'in-card pagination'), but each sentence carries a distinct constraint.

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?

An output schema exists so return values need not be described, and the description covers mode inference, ID requirements, pagination cap, and the render-once contract. Only the offset/propertyToken semantics remain vague, a minor gap for a 5-param tool.

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 coverage is only 40%, and the description compensates for the important parameters: it explains view inference (ROOM when roomId/roomQuery supplied, PROPERTY otherwise) and that roomId must be an exact ID from availability or a unique room name. However, offset and propertyToken are left undocumented, so the 5-param tool is only partially covered.

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 (show/render) and resource (published photos of a property or room), and explicitly distinguishes it from the sibling get_photo_gallery ('data-only for in-card pagination'). An agent can pick between the two without opening either schema.

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?

Gives explicit when-to-use conditions (focused property/room discussion, photos help, UI supported, text-only not requested) and names the alternative get_photo_gallery with the condition that selects it. It also dictates when-not to substitute: 'no substitutions' for room IDs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources