Goose Listen
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| inspect_wavA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.