Ardour Ultra MCP

Overview Schema Source Related Servers Discussions Admin

list_tracks

Read-onlyIdempotent

List and paginate Ardour tracks or routes with stable IDs and mixer state, using name filters, offset/limit paging, and revision checks to inspect a session.

Instructions

Paginate routes with stable Ardour IDs and mixer state.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "request": "<request>"
    },
    "name": "list_tracks"
  }
}

Input Schema

Name	Required	Description	Default
`request`	Yes

Output Schema

Name	Required	Description	Default
`data`	No
`error`	No
`success`	No
`warnings`	No
`revision_after`	No
`changed_objects`	No
`revision_before`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 9, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds genuinely new behavioral context by promising pagination and stable identifiers across calls. It does not, however, explain the pagination contract (defaults, max page size) or why a read-only lister accepts dry_run/confirm_delete fields.

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?

One short front-loaded sentence with no filler, so nothing is wasted. But brevity here crosses into under-specification: the phrase 'paginate routes with ... mixer state' is dense and does not resolve into actionable detail.

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 described. Against that, the tool has a non-obvious parameter surface (filter, revision pinning, delete confirmation) that the description never touches, leaving the agent to open the schema to understand a supposedly simple list call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and there is a single nested request object exposing limit, offset, dry_run, name_filter, confirm_delete and expected_revision. 'Paginate' hints only at limit/offset; name_filter, expected_revision and especially confirm_delete on a read-only listing operation go entirely unexplained, which is a real risk of misuse.

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 sentence states a specific verb ('Paginate') and resource ('routes'), and adds that results carry stable Ardour IDs plus mixer state, which distinguishes it from sibling listers like list_regions or list_groups. It stops short of naming any sibling as the alternative for a different need, and the shift from 'tracks' in the name to 'routes' in the text adds slight ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer from the tool name alone that this is the enumerator for tracks and that add_track_to_group or list_track_plugins cover other needs.

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

Deploy Server