Skip to main content
Glama
deenesjakoruzh
teagan101-cloud

Goose Listen

by teagan101-cloud
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

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.

Related MCP server: MCP Audio Inspector

Run

Requires Node.js 20 or newer.

npm install
npm run build

Launch it with the directory it is allowed to inspect:

GOOSE_LISTEN_ROOT=/path/to/approved/audio node dist/index.js

On Windows 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

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

Available Tools

1 tool
inspect_wavInspect a local WAV recordingA
Read-onlyIdempotent

Read an authorized PCM WAV inside GOOSE_LISTEN_ROOT and return bounded quiet, active, and possible-clipping observations. No network use, transcription, identity inference, or retention.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesRelative or contained absolute path to a PCM WAV file.
window_msNo
activity_thresholdNo

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, and the description adds meaningful beyond annotations: no network use, no transcription, no identity inference, no retention, plus the 'authorized' and 'bounded' constraints. This clearly discloses privacy and access behavior.

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?

Two punchy sentences. The first front-loads the primary behavior with scope and output; the second is a tight list of non-behaviors. No wasted words.

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 read-only tool, the description covers scope, access constraints, output categories, and privacy guarantees. The only notable gaps are the exact output shape and how window_ms/activity_threshold work, but the schema provides defaults and bounds, so the description is still adequate for successful invocation.

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 only 33%, so the description needs to compensate for the undocumented window_ms and activity_threshold parameters. It does not: 'quiet' and 'active' only vaguely relate to activity_threshold, and window_ms is completely unexplained. The agent gets little guidance on how these parameters affect the observations.

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 uses a specific verb ('Read') with a specific resource ('authorized PCM WAV inside GOOSE_LISTEN_ROOT') and states the concrete output ('quiet, active, and possible-clipping observations'). Even without siblings to differentiate from, the behavior is unambiguously defined.

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 conveys clear context: the tool is for local, authorized PCM WAV files within a restricted root, and explicitly lists exclusions (no network, transcription, identity inference, retention). There are no sibling tools to compare against, so not naming alternatives is acceptable.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.1.0
    • First observedinspect_wav
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 1 tool

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count2/5

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.

Completeness2/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers