Skip to main content
Glama
Sign In
Archiware MCP

Archiware MCP

by mnott
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

catalog_migrate

Copies the backup catalogue from an existing MySQL/MariaDB source into the viewer's catalog-db, refusing non-empty targets unless forced and returning only a plan until confirmed.

Instructions

Copies the catalogue database archive_catalog from an existing MySQL/MariaDB (host[:port], read-only on the source) into the viewer's catalog-db: mariadb-dump --single-transaction | mariadb inside the catalog-db container, then compares row counts of sets, tars, entries before/after. Refuses when the target already holds rows unless force:true. Without confirm: only the plan. The password file is read on the machine running the MCP.

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": {
      "from": "<from>",
      "user": "<user>",
      "passwordFile": "<passwordFile>"
    },
    "name": "catalog_migrate"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromYesSource host[:port]
userYes
forceNo
confirmNoMust be true to actually run; without it only the plan/commands are returned
sourceTlsNoverify (default); skip-verify = encrypted but certificate not checked (MySQL 8 self-signed cert); off = no TLS
passwordFileYesFile with the source user's password (on this machine)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.1

TDQS

A4/5.0
Behavior3/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 substantial work: read-only source access, the dump-and-restore pipeline inside the container, row-count comparison of sets/tars/entries before and after, guard on a non-empty target, and a plan-only mode. It leaves real gaps for a data-moving operation, saying nothing about behaviour on mid-copy failure, whether a partial migration is rolled back, or how long a large catalogue takes.

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?

Front-loaded with the resource and direction of the copy, then the guard and the plan-only caveat, so the important facts arrive early. The opening sentence is long and packs the command pipeline in, which costs a little readability but every clause carries operational 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 a six-parameter, annotation-free, output-schema-free mutation tool, the description covers safety gates, source access mode, and target preconditions. It still does not say what the row-count comparison result looks like on the wire, nor what the caller receives in plan-only mode, leaving the agent without a picture of the return value.

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?

Adds meaning well past the 67% schema coverage: confirm is described as the execute gate that otherwise yields plan/commands, force as the override for the non-empty-target refusal, and passwordFile as residing on the machine running the MCP. from is explained as host[:port]. The one unremarked parameter is user, whose semantics (and privilege requirements on the source) are left implicit.

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 (copies the catalogue database archive_catalog) plus source and target (an existing MySQL/MariaDB host into the viewer's catalog-db), and goes further to name the exact mechanism (mariadb-dump --single-transaction | mariadb in the catalog-db container). An agent can distinguish this from catalog_restore or catalog_init purely from this sentence.

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?

Gives clear operating conditions: source is opened read-only, the target must be empty unless force:true, and without confirm the tool returns only the plan. It never explicitly contrasts itself with sibling alternatives like catalog_restore or catalog_init, so the when-to-use-vs-alternative dimension is implied rather than stated.

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