Skip to main content
Glama
Ardour Ultra MCP
by Elias02345

get_session_info

Read-onlyIdempotent

Read an Ardour session's UUID, name, sample rate, and observed revision scope so agents can verify the active project before making edits.

Instructions

Read session UUID, name, sample rate and observed revision scope.

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": "get_session_info"
  }
}

Input Schema

NameRequiredDescriptionDefault
requestYes

Output Schema

NameRequiredDescriptionDefault
dataNo
errorNo
successNo
warningsNo
revision_afterNo
changed_objectsNo
revision_beforeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered structurally. The description adds only the notion of "observed revision scope," which hints the revision value reflects current observed state rather than a requested one, but no further behavioral context (freshness, cost, side effects) is offered.

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?

A single front-loaded sentence with no filler, well suited to a simple read tool. It is perhaps too terse given the unusual request payload, but nothing is wasted.

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 no explanation, and annotations cover the safety profile. However, the odd request object (dry_run/confirm_delete on a read-only tool) is left entirely unexplained, which is the main completeness gap.

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 the single required parameter is a nested "Empty" request object carrying dry_run, confirm_delete, and expected_revision fields. The description says nothing about these fields, leaving the agent to guess why a read operation exposes dry_run/confirm_delete or what expected_revision does.

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 gives a clear verb ("Read") and resource (session) and enumerates the specific fields returned: UUID, name, sample rate, revision scope. It implicitly separates itself from siblings like get_server_info by naming session-level data, though it never explicitly contrasts with them.

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 statement of when to call this versus get_server_info, get_capabilities, or get_transport, and no prerequisites or context conditions are given. The agent must infer usage from the name alone.

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