Skip to main content
Glama
cavi-ai

ableton-mcp

by cavi-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_browser_item_metadata

Read-onlyIdempotent

Read private MCP-managed tags, favorite state, and revision for one exact Ableton Live browser item or local audio sample, preserving Live identity.

Instructions

Read private MCP-managed tags, favorite state, and revision for one exact observed Live browser item or local audio sample. A Live user-folder sample shares the local Splice record only when its URI unambiguously matches a configured local Splice file; reserved URI delimiters and existing separate Live metadata preserve exact Live identity. For a local sample, use root local_splice and path [absolute directory, relative audio path]. Does not read native collections.

Input Schema

NameRequiredDescriptionDefault
pathYesNon-empty path to one item.
rootYesLive browser root or local_splice.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.1
    • removedOutput schema / additionalProperties
      Removed value: -true
    • addedOutput schema / anyOf
      Added value: +[
+  {
+    "properties": {
+      "item": {
+        "type": "object"
+      },
+      "metadata": {
+        "properties": {
+          "favorite": {
+            "type": "boolean"
+          },
+          "revision": {
+            "minimum": 0,
+            "type": "integer"
+          },
+          "tags": {
+            "items": {
+              "type": "string"
+            },
+            "type": "array"
+          }
+        },
+        "required": [
+          "favorite",
+          "tags",
+          "revision"
+        ],
+        "type": "object"
+      },
+      "nativeLiveCollectionsModified": {
+        "const": false
+      }
+    },
+    "required": [
+      "item",
+      "metadata",
+      "nativeLiveCollectionsModified"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "error": {
+        "properties": {
+          "message": {
+            "type": "string"
+          },
+          "outcome": {
+            "enum": [
+              "unknown",
+              "not_executed"
+            ]
+          }
+        },
+        "required": [
+          "message",
+          "outcome"
+        ],
+        "type": "object"
+      }
+    },
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  }
+]
  2. Changed1 schema field changedv0.3.0
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
  3. Changed2 schema fields changedv0.2.0
    • changedInput schema / properties / path / items / description
      Previous value: -"Exact browser path segment."New value: +"Exact browser segment, or [absolute directory, relative audio path] for local_splice."
    • changedInput schema / properties / root / description
      Previous value: -"Live browser root."New value: +"Live browser root or local_splice."
  4. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description adds value by disclosing the data source (private MCP-managed tags, not native Live metadata), an identity-resolution rule for user-folder samples whose URI matches a configured Splice file, and an explicit negative scope ('Does not read native collections'). That is real behavioral context beyond the structured fields, though it stops short of describing pagination or failure modes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first clause, which is good. However, the middle sentence about URI delimiters and 'existing separate Live metadata preserve exact Live identity' is dense, jargon-heavy, and hard to parse, and could be compressed without losing meaning.

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?

An output schema exists, so return values need not be explained, and the tricky identity edge case is covered. The missing piece is provenance: the agent is told the item must be 'exact observed' but not where to obtain a valid root/path (list_browser_roots, list_local_splice_roots, or the search tools), which matters for a 2-required-param lookup tool.

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 both root and path are already documented in the schema, including the local_splice two-element path form. The description largely restates that mapping and adds only marginal semantics (the notion of a 'configured local Splice file'), so baseline 3 applies.

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?

States a specific verb and resource ('Read private MCP-managed tags, favorite state, and revision') for exactly one item, and the closing 'Does not read native collections' carves out scope. It does not name its siblings (set_browser_item_metadata, search_browser_item_metadata, get_browser_items), so the read-vs-write-vs-search distinction must be inferred from the verb.

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?

The description implies usage via 'one exact observed ... item', meaning it applies when identity is already known, but it never states when to choose this over get_browser_items, search_browser_item_metadata, or get_preset_metadata. The local_splice sentence is parameter guidance rather than when-to-use guidance, and there are no stated prerequisites or exclusions relative to siblings.

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