Skip to main content
Glama

vibedeploy

by be.vibedeploy
OverviewDiscussionsAdmin

List deploy/snapshot history for a site

list_history
Read-onlyIdempotent

Return the most recent 50 deploy and snapshot history entries for a site, newest first. Includes the source (how it was triggered), an optional label, the associated Longhorn snapshot name (if any), the file count, and the number of secrets detected. Each entry's snapshot holds the content from BEFORE that entry (restoring it undoes the entry). Any team member can read history.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
siteIdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
entriesYesMost recent 50 deploy/snapshot history entries, newest first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / entries / items / properties / snapshotName / description
      Previous value: -"Longhorn snapshot name for this entry, or null if no snapshot is associated (or it was pruned by retention)."New value: +"Longhorn snapshot taken immediately BEFORE this entry's change (pre-deploy, pre-promote, pre-restore), so restoring it brings back the content that was live before this entry, not this entry's own content. For manual-snapshot and staging entries it is the live content at that moment. To bring back the content of an older deploy, use the snapshot of the next newer entry. Null if none was taken or it was pruned by retention."
  2. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}
  3. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  4. First observed

TDQS

A4/5.0
Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds meaningful behavioral details: the 50-entry cap, ordering, included fields, and the important semantic that each entry's snapshot holds content from before that entry and restoring it undoes the entry. No contradiction exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: the first gives the core behavior and ordering, the second lists included fields, and the third adds the snapshot semantics. Every sentence earns its place and the most important information is front-loaded.

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?

The output schema covers return fields and annotations cover safety, but the missing parameter semantics for two optional-looking parameters is a real gap for correct invocation. The description is strong on behavior but incomplete on how to target the site.

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% and the description does not explain what 'name' or 'siteId' mean, which is required, or how they relate. The phrase 'for a site' hints at the resource but does not compensate for two undocumented parameters.

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?

The description uses a specific verb and resource: it returns the most recent 50 deploy and snapshot history entries for a site, newest first. It also clearly differentiates itself from siblings like list_deploys and list_snapshots by combining both types into one history view.

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?

The description implies this tool is for getting a combined deploy/snapshot history view and notes that any team member can read it, but it does not explicitly state when to use this versus list_deploys or list_snapshots, nor does it mention exclusions or alternatives.

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

All vibedeploy toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources