PostFader V12 — FL Studio MCP Server

Overview Schema Source Related Servers Discussions Admin

sound_get_history

Read-onlyIdempotent

Reports local sound-selection history—location, health, and accepted/rejected record counts—so you can inspect how past choices steer future palettes. Read-only.

Instructions

Report the local sound-selection history: location, health, and record counts.

Read-only. History stores accepted and rejected choices on this computer
to steer later palettes. Use sound_reset_history only when the user asks
to clear it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`path`	Yes
`error`	No
`exists`	Yes
`corrupt`	Yes
`healthy`	Yes
`warnings`	No
`max_records`	Yes
`max_feedback`	Yes
`record_count`	No
`feedback_count`	No
`schema_version`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv11.0.2Oct 5, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful non-structured context: that history persists locally on this computer and stores accepted and rejected choices that steer later palettes.

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?

Three short, front-loaded sentences with no filler: purpose first, then the read-only nature, then the sibling routing. Every sentence earns its place.

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 exists, so return-value detail is unnecessary. The description covers what the tool reports, its persistence model, and when to use the clearing sibling, which is complete for a parameterless read tool.

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 of 4 applies per the rubric. There are no argument semantics that could meaningfully be elaborated.

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?

The description names a specific verb ('Report'), a precise resource ('local sound-selection history'), and enumerates the reported fields (location, health, record counts). This cleanly distinguishes it from siblings like project_get_history, which covers project rather than sound-selection history.

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?

It explicitly routes the destructive counterpart: 'Use sound_reset_history only when the user asks to clear it,' giving a clear condition and alternative. It does not state when to prefer this over siblings like sound_get_inventory, so it stops short of full when/when-not coverage.

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

Deploy Server