Skip to main content
Glama
putervision

state-memory-mcp

by putervision
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

manage_database

Destructive

Back up, restore, audit, merge, and diff physical SQLite databases and Git branch state to resolve corruption and cross-branch conflicts.

Instructions

Physical SQLite database maintenance, backups, integrity checks, and Git VCS state sync (actions: backup, restore, audit, merge, branch_diff, branch_merge). Use manage_database instead of manage_snapshots when managing physical SQLite files, cross-branch merges, or database corruption audits.

Returns database backup path, foreign key integrity report, branch merge conflict report, or diff.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoForce overwrite during restore or merge.
actionYesThe database administration or VCS sync action to execute: backup, restore, audit, merge, branch_diff, branch_merge.
projectNoTarget project name or slug.
backupPathNoSource backup file path for restore.
outputPathNoTarget destination file path for backup.
sourcePathNoSource SQLite database path for merge.
source_branchNoSource git branch for branch_merge.
target_branchNoTarget git branch to compare or merge against.
resolution_strategyNoConflict resolution strategy for branch_merge.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.3.1
    • changedInput schema / properties / action / description
      Previous value: -"The database administration or VCS sync action to execute."New value: +"The database administration or VCS sync action to execute: backup, restore, audit, merge, branch_diff, branch_merge."
    • addedInput schema / properties / action / enum
      Added value: +[
+  "backup",
+  "restore",
+  "audit",
+  "merge",
+  "branch_diff",
+  "branch_merge"
+]
  2. Changed3 schema fields changedv1.2.1
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • removedInput schema / additionalProperties
      Removed value: -true
    • addedInput schema / required
      Added value: +[
+  "action"
+]
  3. Addedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds useful context about VCS sync and return types, but it does not go beyond annotations to explain which actions overwrite data, what permissions are needed, or how conflicts are resolved. A 3 is appropriate given the annotations carry the main behavioral burden.

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 sentences, each earning its place: the first scopes the tool and lists actions, the second routes from a sibling, and the third summarizes return values. It is front-loaded and contains no redundant filler.

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?

The description covers the tool's purpose, alternative sibling, and return values, and the annotations plus full schema coverage handle safety and parameter semantics. It does not explicitly map which parameters apply to which action, though the schema descriptions do this adequately. The definition is complete enough for correct invocation.

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 parameter already has a semantic description in the schema. The description lists the actions but does not add syntax, format, or conditional logic beyond what the schema provides, making the baseline 3 correct.

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 states a specific verb and resource ('Physical SQLite database maintenance, backups, integrity checks, and Git VCS state sync') and enumerates all six actions. It also explicitly distinguishes itself from the sibling manage_snapshots, so an agent can tell what this tool does without opening the schema.

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?

It gives explicit routing guidance: use manage_database instead of manage_snapshots when managing physical SQLite files, cross-branch merges, or database corruption audits. This names the alternative and the condition that selects it, leaving little 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