Skip to main content
Glama

Download Unit Attachment

download_unit_attachment
Read-onlyIdempotent

Download and READ a file attached to a unit's UDF.

The unit equivalent of download_property_attachment: titles, certificates of occupancy, inspection reports and anything else filed on a unit's File-type UDFs. PDF pages are rendered so the contents can be read, not just saved. When the unit holds exactly one file, udf_name is optional.

For unit PHOTOS — the IMAGES tab or image UDFs — use get_unit_images.

``location`` (optional): a single Rent Manager Location ID. Required
when the connection has several Locations (see ``list_locations``);
this tool never fans out across Locations.

Input Schema

NameRequiredDescriptionDefault
pagesNo
file_idNo
save_asNo
unit_idNo
locationNo
udf_nameNo
as_imagesNo
max_pagesNo
shortnameNo
unit_nameNo
property_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "result": {
      -      "title": "Result"
      -    }
      -  },
      -  "required": [
      -    "result"
      -  ],
      -  "title": "download_unit_attachmentOutput",
      -  "type": "object"
      -}New value: +null
  2. Changed2 schema fields changed
    • addedInput schema / properties / location
      Added value: +{
      +  "default": "",
      +  "title": "Location",
      +  "type": "string"
      +}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "result": {
      +      "title": "Result"
      +    }
      +  },
      +  "required": [
      +    "result"
      +  ],
      +  "title": "download_unit_attachmentOutput",
      +  "type": "object"
      +}
  3. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/openWorld, so the description earns credit for adding non-obvious mechanics: PDF pages are rendered for reading rather than just saved, and the tool never fans out across Locations. It stops short of covering save_as, as_images, or max_pages behavior, which materially change what comes back.

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 core differentiator is front-loaded in the first sentence, with the exclusions and the location caveat following. Slightly padded by the parenthetical 'not just saved' and a location block that could be one line, but nearly every sentence carries information.

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 an 11-parameter tool with no output schema and no schema descriptions, the description covers selection and location semantics well but leaves the majority of inputs unexplained. An agent can pick the right tool yet may have to guess at page selection, image rendering, and save-path arguments.

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

Parameters2/5

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

Schema coverage is 0% across 11 parameters. The description explains location (required when multiple Locations exist) and the conditional optionality of udf_name, but leaves file_id, unit_id, property_id, shortname, unit_name, pages, max_pages, as_images and save_as entirely undocumented in both places.

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 ('Download and READ a file attached to a unit's UDF') and enumerates the document types that live there. It also names the sibling tool for the adjacent case, so an agent can separate this from download_property_attachment and get_unit_images without opening a schema.

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?

Explicitly routes photos to get_unit_images and notes udf_name is optional when the unit holds exactly one file. It also gives a prerequisite for the location argument, but never states the positive trigger condition (a file-type UDF on the unit) or what to do when no attachment exists.

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