Skip to main content
Glama

VibeDeploy

by be.vibedeploy
OverviewDiscussionsAdmin

List deploy/snapshot history for a site

list_history
Read-onlyIdempotent

Return the site's last 50 deploy and snapshot entries, newest first: how each was triggered, label, snapshot name, file count and secrets detected. Each entry's snapshot holds the content from BEFORE that entry. Restoring is done by the user in the VibeDeploy dashboard within the plan's restore window; there is no restore tool.

Input Schema

NameRequiredDescriptionDefault
nameNoSite name as shown by list_sites, e.g. my-portfolio. Provide name or siteId.
siteIdNoSite id from list_sites or get_site. Use instead of name.

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / name / description
      Added value: +"Site name as shown by list_sites, e.g. my-portfolio. Provide name or siteId."
    • addedInput schema / properties / siteId / description
      Added value: +"Site id from list_sites or get_site. Use instead of name."
    • changedOutput schema / properties / entries / items / properties / snapshotName / description
      Previous 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."New value: +"Snapshot taken just BEFORE this entry's change, so restoring it brings back what was live before this entry. For manual-snapshot and staging entries it is the live content at that moment. To get an older deploy's own content back, use the snapshot of the next newer entry. Null if none was taken or retention removed it."
  2. 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."
  3. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}
  4. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  5. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already cover the read-only and idempotent nature, but the description adds substantial behavioral context: a 50-entry limit, newest-first ordering, the fact that each snapshot holds content from before its entry, and that restoration happens outside the tool within the plan's restore window.

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?

The description is front-loaded with the core action and return scope, then adds two compact sentences that clarify snapshot semantics and the absence of a restore tool. Every sentence carries relevant information without waste.

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?

Given the output schema and annotations, the description is complete enough to call the tool correctly: it states the return limit, ordering, entry fields, snapshot timing, and the restore limitation. No critical context 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 name and siteId are fully documented in the input schema. The description adds no additional parameter meaning, making a baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: returns the site's last 50 deploy and snapshot entries, newest first. It distinguishes itself by combining deploy and snapshot history, but does not explicitly name or differentiate itself from sibling tools like list_deploys or list_snapshots.

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?

Usage is implied by the purpose, and the description usefully states that restoring is done in the dashboard with no restore tool available. However, it gives no explicit guidance on when to choose list_history instead of sibling listing tools such as list_deploys or list_snapshots.

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