Skip to main content
Glama
rosasynthesiz

Logic Pro MCP

by rosasynthesiz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

logic_offline

List and rename track, folder, or group names inside a .logicx project file without driving Logic's UI, writing to an APFS clone by default.

Instructions

Read or rename track/folder/group names INSIDE a .logicx file, without driving Logic's UI.

list:   every patchable name in the project (kind: track | folder | group), plus counts.
rename: apply changes [{"old","new","kind"?}] to the project's ProjectData. By default writes to an
        APFS clone "<name> OFFLINE.logicx" next to the original (instant, no data copied); in_place
        patches the original after saving ProjectData.bak, and is refused while Logic has that
        document open (Logic would overwrite it on save). Returns uncertain: only Logic reopening
        the file proves the edit, so open the result and read the names back.

Input Schema

NameRequiredDescriptionDefault
actionYes
changesNo
projectYes
in_placeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so richly: default writes to an APFS clone next to the original, in_place patches the original only after saving ProjectData.bak and is refused while Logic holds the document, and the result is explicitly 'uncertain' until Logic reopens the file. These are exactly the mutation, backup, and verification behaviors an agent needs.

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 core sentence followed by tight list:/rename: sections; every clause adds operational value (clone mechanics, backup, refusal condition, verification caveat). Slightly dense in the rename block but no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter, no-annotations, no-output-schema mutation tool, the description covers actions, destination semantics, safety/backup behavior, failure conditions, and the limits of the return value. Nothing needed to invoke it correctly is missing.

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 description coverage is 0%, so the description must compensate; it documents the changes array shape ({"old","new","kind"?}), the in_place flag's effect, and the list/rename action split. The project parameter is only implied ('next to the original', 'inside a .logicx file') rather than stated as a file path, leaving a small gap.

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 pair (read/rename) and a precise resource (track/folder/group names inside a .logicx file) and immediately distinguishes itself from every sibling by noting it operates 'without driving Logic's UI.' An agent can tell this apart from logic_project/logic_tracks 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly differentiates the two actions with 'list:' and 'rename:' labels and explains when in_place is appropriate (and when it is refused: while Logic has the document open), steering toward the safe clone default. It stops short of explicitly comparing to sibling tools, but the offline framing implies when it should be preferred over UI-driving tools.

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