Skip to main content
Glama

Browse backup files

browse_restore_files
Idempotent

Browse one directory inside a backup point: queues an asynchronous listing job, paginates results, and never restores files.

Instructions

Create a persisted asynchronous browse job to list one directory inside a backup point. This queues worker activity and stores the listing result; it does not restore files, change backup contents or the running server, or charge the account. Start at the backup root by passing only backupPointId. To open a subdirectory, pass sourceBrowseId plus the directoryEntryId of a type=directory entry from that result; filesystem paths are never accepted. A directory can hold an enormous number of files, so the server selects pages of 200 or 1,000 entries: while result.nextOffset is non-null, call again with the same sourceBrowseId and directoryEntryId and offset set to result.nextOffset. Use result.pageSize rather than assuming 200 when moving backwards. When nextOffset is null the listing cannot be paged further even if truncated is true — that is a capped scan; check result.listingStatus: 'complete' means the folder was read end to end, 'partial' means the listing is a bounded lower-bound slice, so never present it as the whole folder. Optionally pass filter to search entry NAMES in that one directory (substring, case-insensitive, never recursive) — but only when list_restore_file_points reported searchAvailable=true, otherwise this tool refuses rather than silently returning an unfiltered listing. The call is asynchronous: it returns a browse id in a pending state, and you must poll get_restore_file_browse until state is succeeded. Requires services:read and, because it is a POST, an API key that permits write operations plus an idempotencyKey.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filterNoCase-insensitive substring matched against entry NAMES in the browsed directory only. It never matches full paths and never searches subdirectories. Requires node search capability; check searchAvailable from list_restore_file_points first.
offsetNoCopy a non-null result.nextOffset to page further through the SAME directory (a null nextOffset means the listing cannot be paged further). Must be 0 (or omitted) when starting a root listing or entering a directory.
orderNoYesTenant-owned service order number: 1-64 ASCII letters, digits or hyphens, e.g. VP12345 or VP12345-1
backupPointIdYesBackup point ID returned by list_restore_file_points
idempotencyKeyYesClient-global unique key for this exact browse request; reuse it only to replay the same request.
sourceBrowseIdNoBrowse id of the succeeded listing the directory entry came from. Omit to list the backup root.
directoryEntryIdNoOpaque id of a type=directory entry from the source browse result. Filesystem paths are never accepted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.16

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond annotations: declares the call is asynchronous and returns a pending browse id, requires services:read and a write-capable API key because it is a POST, requires an idempotencyKey, and warns that 'partial'/'truncated' listings are bounded lower-bound slices that must never be presented as a whole folder. This is rich context the structured annotations do not carry.

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?

Purpose and the 'does not' scope are front-loaded, but the body is a single dense paragraph that mixes paging, filtering, and async semantics. Nearly every clause earns its place, though breaking the paging and filter rules into separate sentences would improve scannability.

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?

There is no output schema, so the description must carry the return contract — and it does: pending browse id, state polling via get_restore_file_browse, result.nextOffset, result.pageSize, truncated, and listingStatus 'complete' vs 'partial'. Complete for a 7-parameter async tool.

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 already 100%, so baseline is 3, but the description adds relational meaning the schema fields do not: sourceBrowseId and directoryEntryId must be used as a pair from the same result, paths are never accepted, offset must be 0 when entering a directory, and pageSize should be read from the result rather than assumed. That is genuine added value over the per-field descriptions.

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 ('Create a persisted asynchronous browse job to list one directory inside a backup point') and immediately scopes what it is NOT ('does not restore files, change backup contents or the running server, or charge the account'). This cleanly separates it from list_restore_file_points and get_restore_file_browse.

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?

Explicit entry conditions (root via backupPointId, subdirectory via sourceBrowseId + directoryEntryId), explicit paging loop (while result.nextOffset is non-null, call again with same sourceBrowseId/directoryEntryId and offset), the filter precondition (searchAvailable=true from list_restore_file_points), and the follow-up step (poll get_restore_file_browse until succeeded). Nothing is left to inference.

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