Gizmos Audacity MCP

Overview Schema Source Related Servers Discussions Admin

Project Info

audacity_project_info

Reads Audacity project tracks, clips, selection, length, active paths, and actual render sample rate, restoring selection after measurement; empty projects return a null rate plus default preference.

Instructions

Read project tracks, clips, selection, length, active project paths and actual render sample rate. Rate is measured by a tiny temporary WAV export with selection restored; an empty project returns rate=null and its default preference separately.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "audacity_project_info"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`rate`	Yes
`clips`	Yes
`tracks`	Yes
`selection`	Yes
`fileSource`	Yes
`defaultRate`	Yes
`lengthSeconds`	Yes
`activeProjectFiles`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

With readOnlyHint=false already declared, the description adds the missing why: sample rate is obtained via 'a tiny temporary WAV export with selection restored', which discloses the side effect and the state restoration that justifies the non-read-only annotation. It also covers the empty-project edge case (rate=null with the default preference reported separately), which is exactly the kind of behavioral context annotations cannot carry.

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?

Two sentences, front-loaded with the returned data followed by the measurement mechanism and edge case. The second sentence is densely packed ('tiny temporary WAV export with selection restored') but every clause carries information an agent needs.

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?

An output schema documents the return shape, annotations cover the safety profile, and the description fills the remaining gaps: the sampling mechanism, selection restoration, and the empty-project behavior. For a zero-parameter inspection tool this is complete.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond confirming that no input is needed to obtain the full project snapshot.

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 opens with a specific verb-plus-resource pairing ('Read project tracks, clips, selection, length, active project paths and actual render sample rate') and enumerates the exact contents, which separates it in spirit from the app-level audacity_info and the file-oriented audacity_project. It never names a sibling or states the boundary explicitly, so it stops short of full differentiation.

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 only implied: an agent can infer this is the tool for inspecting the current project's state. There is no explicit 'use this when…' guidance, no statement of when to prefer audacity_info or audacity_measure instead, and no prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server