Skip to main content
Glama
synopsys0

PostFader V10 — FL Studio MCP Server

postfader_review_delete

Destructive

Remove a review session's metadata while keeping audio and project files intact. Specify the review session ID and confirm to delete only the saved review record.

Instructions

Delete one Review Session record without touching audio or the FL project.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmYesMust be true after an explicit request to delete review metadata.
review_session_idYesReview Session metadata to delete.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
deletedYes
messageYes
process_localNo
review_session_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv10.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already indicate destructiveHint=true and idempotentHint=false, and the description adds the key behavioral reassurance that audio and the FL project are untouched. It clarifies exactly what will be destroyed: review session metadata only.

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

Conciseness5/5

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

A single front-loaded sentence conveys the action, resource, and destructive scope with zero wasted words. Important safety context (audio and project untouched) is included without bloat.

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

Completeness4/5

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

For a simple two-parameter delete operation with a confirm flag plus an output schema and destructive annotations, the description is nearly complete. It could have additionally stated that deletion is irreversible, but annotations and the confirm parameter already signal the destructive nature.

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%, and the parameter-level descriptions already explain review_session_id as the metadata to delete and confirm as a required explicit-deletion flag. The description adds no extra parameter meaning beyond this, so the baseline of 3 is appropriate.

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 action ("Delete one Review Session record") with a clear resource and an explicit scope boundary ("without touching audio or the FL project"). This distinguishes it from broader destructive audio/project tools and from review tools that do more than delete metadata.

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?

The description makes the use case clear: the agent should use this when deleting a single review session record while preserving audio and project state. It does not explicitly name sibling alternatives, but the metadata-only scope is enough to route an agent correctly.

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