Goose Listen
# Goose Listen
Goose Listen is a small, local-first MCP extension that turns a PCM WAV file into bounded audio observations an agent can reason about without uploading the recording or pretending to understand more than the signal supports.
The first working slice answers narrow questions:
- When is the recording quiet or active?
- Where might clipping have occurred?
- What are the sample rate, channel count, duration, peak, and RMS level?
- What uncertainty and privacy boundary should accompany those observations?
It deliberately does **not** transcribe speech, identify people, infer emotion, or call a remote model.
## Why this fits Goose
Goose treats external capabilities as MCP extensions. Goose Listen is a command-based stdio MCP server, so it can be launched locally and used as one bounded observation tool. The event envelope is intentionally neutral enough to support future microphones, replay fixtures, and optional on-device processors without coupling the core to one model.
## Run
Requires Node.js 20 or newer.
```sh
npm install
npm run build
```
Launch it with the directory it is allowed to inspect:
```sh
GOOSE_LISTEN_ROOT=/path/to/approved/audio node dist/index.js
```
On Windows PowerShell:
```powershell
$env:GOOSE_LISTEN_ROOT = 'C:\path\to\approved\audio'
node dist/index.js
```
Add it to Goose as a custom command-line extension using `node` as the command and the absolute `dist/index.js` path as its argument. Keep the transport as stdio.
## Tool
### `inspect_wav`
Inputs:
- `file`: a relative path under `GOOSE_LISTEN_ROOT`, or an absolute path still contained by it
- `window_ms`: observation window from 50 to 2,000 ms; default 250
- `activity_threshold`: RMS threshold from 0 to 1; default 0.02
Output:
- deterministic file metadata
- overall RMS and peak
- coalesced `quiet`, `active`, and `possible_clipping` segments
- explicit limitations and a no-retention statement
## Verify
```sh
npm test
npm run check
npm run build
```
The tests generate their own short WAV fixture, verify observations, reject a path outside the approved root, and reject a non-WAV payload.
## Roadmap
1. A permission-scoped microphone adapter with an obvious recording indicator
2. Deterministic replay fixtures for agent evaluations
3. Optional, separately consented on-device speech-to-text processors
4. Cross-platform packaging and Goose recipes
5. Accessibility evaluation with users who benefit from hands-free workflows
## License
MIT
TDQS
Scored across 1 tool
With only one tool in the server, there is no possibility of confusion between tools. The single inspect_wav operation is clearly described with a specific, unique purpose.
The tool name inspect_wav follows a clear verb_noun pattern and is readable. However, a single tool provides too little evidence to fully assess naming consistency across a server.
A single tool is far too few for a typical server surface, making it feel more like a one-off utility than a coherent tool set. Even a focused audio inspection server would benefit from additional operations such as listing files or retrieving metadata.
The surface is severely incomplete: it offers only one analysis operation with no way to enumerate available WAV files, access file metadata, or handle broader workflows. Agents would hit dead ends and be forced to rely on external mechanisms for basic context.