Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

viewer_deploy

Deploys a read-only catalogue viewer on a Docker host over SSH, provisioning MariaDB, credentials, and nightly dumps, then wiring MCP config after health checks.

Instructions

Deploys the catalogue viewer on a docker host over ssh: a read-only web page, its own MariaDB (database archive_catalog, users catalog read/write for this MCP and catalog_ro SELECT-only for the page, data dir on the host) and a nightly dump service. Generates random passwords and the viewer login into /secrets (mode 600), copies web/, runs docker compose up -d --build, waits for health, runs catalog_init against the new database and points the MCP config (catalogMysqlContainer, catalogDbCnf) at it when the docker host is the P5 host. Without confirm: only the plan. With confirm:true the result contains the generated viewer password ONCE.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "network": "<network>",
      "catalogIp": "<catalogIp>",
      "dbIp": "<dbIp>"
    },
    "name": "viewer_deploy"
  }
}

Input Schema

NameRequiredDescriptionDefault
tzNoTime zone of the containers (default UTC)
dirNoInstall dir on the host (default /opt/catalog-viewer)
dbIpYesFree IPv4 on that network for the database (port 3306)
hostNoDocker host (ssh target); default viewerHost or the P5 host
confirmNoMust be true to actually run; without it only the plan/commands are returned
dataDirNoDatabase data dir on the host (default <dir>/data/db)
networkYesExisting external docker network name
p5IndexNoP5 config/index/backup dir on the host (default derived from the config)
subpathNoReverse-proxy sub-path, e.g. viewer (only adds an Apache example to the result)
packRootNoPack root on the host (default config packRoot)
catalogIpYesFree IPv4 on that network for the web page
p5BaseUrlNoLink target for 'P5 web UI' on the page
viewerUserNoViewer login name (default viewer)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does so well: it discloses side effects beyond the obvious, including generating random passwords into a mode-600 secrets file, copying web/, running 'docker compose up -d --build', waiting on health, running catalog_init, and rewriting the MCP config (catalogMysqlContainer, catalogDbCnf). It also warns that the viewer password is returned only ONCE. The notable gap is failure and idempotency semantics — it doesn't say what happens on a partial failure or whether re-running against an existing install overwrites or aborts.

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 deployment flow is front-loaded in the first clause and every sentence carries substantive information — nothing is filler. However, the opening sentence is a long run-on with deeply nested parentheticals, which makes the critical side effects (config rewrite, one-time password) harder to scan than they should be. Slight restructuring into a short summary plus a bulleted effect list would improve it.

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?

For a 13-parameter, no-annotation, no-output-schema deployment tool, the description covers the essential arc: prerequisites (existing external network, ssh docker host), what is created, the dry-run default, and the one-time secret return. What is missing is failure/rollback behavior and any statement about prerequisites like host access or MCP config ownership when the host is not the P5 host. Strong overall, but not fully closed.

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 every one of the 13 parameters is already documented in the input schema, establishing a baseline of 3. The description adds some connective meaning — the confirm gate, the <dir>/secrets location, and the data-dir placement — but does not elaborate on the interaction between network, catalogIp, and dbIp or explain the p5Index/p5BaseUrl derivation. It neither compensates for nor undercuts the schema.

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 opens with a specific verb and resource — 'Deploys the catalogue viewer on a docker host over ssh' — and then enumerates exactly what gets provisioned (read-only web page, dedicated MariaDB with named databases/users, nightly dump service). An agent knows precisely what this tool builds. It never names a sibling such as viewer_status or catalog_init to contrast against, so it stops short of a 5.

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 context is implied rather than stated: the only explicit guidance is the confirm gate ('Without confirm: only the plan. With confirm:true...'), which tells the agent how to trigger a real deploy versus a dry run. There is no statement of when this tool should be chosen over catalog_init, viewer_status, or container_start, and no 'do not use if already deployed' exclusion. Adequate but leaves the routing decision 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