Skip to main content
Glama
NovaLux12

SpotifyMCP

by NovaLux12
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

import_profile_state

Restore local Spotify sidecar stores from a profile-state archive, merging or overwriting data with optional dry-run preview and backups.

Instructions

Restore local sidecar stores from a profile-state archive. merge unions each store on its own keys and de-duplicates search_history by entry id; overwrite replaces each store, keeping a 0600 .bak of what it replaced. The mutation ledger (stores.mutations_history) is export-only: it is never appended to or replaced, and an archive carrying it is reported as skipped. dry_run reports the per-store plan and writes nothing. Refuses newer schema versions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNomerge = union on each store's own keys; overwrite = replace, keeping a .bakmerge
dry_runNoPreview only: validate inputs and describe exactly what would change without performing it
input_pathYesPath to the profile-state archive JSON file
response_formatNo'concise' = human prose, 'detailed' = more fields in prose, 'json' = raw API objectconcise

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.2
    • addedInput schema / properties / dry_run
      Added value: +{
+  "description": "Preview only: validate inputs and describe exactly what would change without performing it",
+  "type": "boolean"
+}
    • changedInput schema / properties / mode / description
      Previous value: -"merge = add to existing stores; overwrite = replace them"New value: +"merge = union on each store's own keys; overwrite = replace, keeping a .bak"
  2. Changed2 schema fields changedv1.31.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv1.26.1

TDQS

A4.1/5.0
Behavior5/5

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

With only destructiveHint=false available, the description carries real load: merge de-duplicates search_history by entry id, overwrite keeps a 0600 .bak of replaced stores, the mutation ledger is export-only and reported as skipped, dry_run writes nothing, and newer schema versions are refused. This is exactly the mutation/recovery context an agent cannot get from annotations.

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?

Front-loaded with what the tool does, then mode semantics, then edge cases (ledger, dry_run, schema version). Every clause is operational information; there is no 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?

For an unannotated-in-practice mutation tool with no output schema, the description covers modes, side effects, backups, exclusions, and preview behavior well. Minor gaps remain: no statement of required permissions or what happens on partial/validation failure, and no hint at the dry_run plan's shape beyond 'per-store plan'.

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?

Schema coverage is already 100%, so 3 is the baseline; the description goes beyond the schema by spelling out the de-duplication key (entry id) that merge uses and reinforcing the dry_run/ledger rules. input_path and response_format are left to the schema, which is acceptable given how well the two enums are documented.

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 gives a specific verb+resource+scope: 'Restore local sidecar stores from a profile-state archive', which an agent can act on immediately. It does not, however, differentiate itself from the closely named sibling import_from_sidecar or from restore_library_snapshot, leaving a selection ambiguity.

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 rather than stated: the merge/overwrite semantics and dry_run behavior tell the agent how to call it, but there is no explicit when-to-use guidance relative to import_from_sidecar or restore_library_snapshot, and no stated prerequisites beyond the schema-version refusal.

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