Skip to main content
Glama
Sign In
Strudel MCP Server

Strudel MCP Server

by williamzujkowski
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

pattern_store

Persist Strudel music patterns by saving named patterns to disk, loading them into sessions, and listing the catalog with optional tag filters.

Instructions

Persist patterns to disk and read them back. Use action=save to write the current session pattern under a name; action=load to restore a named pattern into the current session; action=list to enumerate the on-disk catalog (optionally filtered by tag). Example: pattern_store({ action: "save", name: "my-jam", tags: ["techno"] }). For session lifecycle (create/destroy/list active sessions) use the session tool — pattern_store deals with on-disk patterns, not runtime sessions.

Input Schema

NameRequiredDescriptionDefault
tagNoFilter by tag (list only)
nameNoPattern name (required for save/load)
tagsNoTags to attach (save only)
actionYesWhich on-disk operation to perform
overwriteNosave only: replace a pattern saved under a DIFFERENT name that maps to the same file (names are lowercased and stripped of punctuation, so "My Jam" and "my-jam" collide). Off by default; the replaced pattern is unrecoverable.
session_idNoOptional session ID (#108). Sources/targets the named session's current pattern; the on-disk catalog is shared across sessions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.1.1
    • addedInput schema / properties / overwrite
      Added value: +{
+  "description": "save only: replace a pattern saved under a DIFFERENT name that maps to the same file (names are lowercased and stripped of punctuation, so \"My Jam\" and \"my-jam\" collide). Off by default; the replaced pattern is unrecoverable.",
+  "type": "boolean"
+}
  2. Addedv4.0.0

TDQS

A4.3/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that load mutates the current session and that the catalog is on-disk, but it omits the riskiest trait — the overwrite/collision behavior and irreversibility — which appears only in the schema's overwrite field rather than in the description. It also says nothing about return content or error behavior, so the safety profile is only partially surfaced.

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 purpose, then actions, then an example, then a sibling redirect — a sensible information hierarchy with no filler sentences. The example is slightly redundant with the enumerated actions, but it earns its place by showing the argument shape.

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?

No output schema exists, so the description ideally would say what save/load/list return (e.g., catalog entry shape), and it does not. Otherwise it is sufficiently complete for a 6-parameter persistence tool: operation semantics, tag filtering, and tool boundaries are all covered.

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 100%, so the baseline is 3, but the description adds meaning beyond the field docs by explaining how each action value interacts with session state (save reads the current session pattern; load replaces it) and by clarifying the tag filter only applies to list. The collision/overwrite semantics and session_id scoping are left entirely to the schema.

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?

Opens with a specific verb pair and resource: "Persist patterns to disk and read them back," then enumerates the three operations (save/load/list) with what each does. It also explicitly scopes itself as the on-disk tool versus the runtime 'session' sibling, so an agent can separate it from the rest of the list without opening schemas.

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?

States the selection rule for each action (save = write current session pattern under a name; load = restore a named pattern; list = enumerate catalog, optionally tag-filtered) and gives a concrete call example. It also names the alternative tool and the condition that selects it: session lifecycle goes to the session tool, not here.

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