de en es ja ko ru zh

web perception

Name: web perception
Author: asume21

by asume21

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

webear

npm version npm downloads License: MIT MCP Compatible

Gib deiner KI echte Sinne — hören, sehen und fühlen jede Web-App.

Ein MCP-Server + Browser-SDK, das KI-Codierungsassistenten direkten sensorischen Zugriff auf eine laufende Web-Anwendung verschafft. Audio, Visuelles, Performance, Netzwerk, Sicherheit und Konsole — vom Browser erfasst, in Echtzeit analysiert, über MCP bereitgestellt.

„Der Beat klingt matschig" — deine KI erfasst 3 Sekunden, misst den spektralen Schwerpunkt bei 580 Hz und 45 % Energie unter 250 Hz und sagt dir genau, warum.

Demo der Web-Perception

Was es tut

Tool	Beschreibung
`capture_audio`	Nimm einen kurzen Clip (500 ms–30 s) dessen auf, was deine Web-App gerade ausgibt
`analyze_audio`	Signalanalyse: RMS, Spitzenpegel in dB, Clipping, Spektralzentrum, Frequenzbereichen, BPM, Verpackung
`describe_audio`	KI-Beschreibung in verständlicher Sprachbild — „Der Kick ist druckvoll, mit viel Sub-Aufbau um 80 Hz"
`diff_audio`	Vergleiche zwei Aufnahmen und Lage der Änderungen — Lautstärke, Ton, Timing, Clipping

Related MCP server: broca-machina

So funktioniert es

Browser (Web Audio API)
    ↓ MediaRecorder taps the AudioContext output node
    ↓ Uploads WebM blob via HTTP POST
Express Middleware (your dev server)
    ↓ Stores captures in memory, dispatches commands via SSE
MCP Server (stdio — runs inside your IDE)
    ↓ Retrieves captures, sends to CodedSwitch analysis API
AI Coding Assistant
    → "Your bass band is 42% of the mix (high), spectral centroid
       is 580 Hz (muddy), and timing jitter is 23ms — the scheduler
       is drifting under load."

Der entscheidende Unterschied zu allen anderen Audio-MCPs: Es greift direkt auf den Web-Audio-Graph zu, damit umgeht es Raumakustik, Mikrofon-Hardware und die Notwendigkeit Dateien zu exponieren.

Schnellstart

1. Installieren

npm install webear

2. Die Express-Middleware zum Dev-Server hinzufügen

import express from 'express'
import { webearMiddleware } from 'webear/middleware'

const app = express()
app.use(express.json())

// Mount the audio debug bridge (automatically disabled in production)
app.use('/api/webear', webearMiddleware())

app.listen(5000)

3. Das Client-Snippet zur Web-App hinzufügen

Option A — alles sauber automatisch erkennen (Tone.js oder unbehandeltes Web Audio)

import WebEar from 'webear/client'
WebEar.init()

Option B — htt vor-Beurteilung

const ctx = new AudioContext()
const masterGain = ctx.createGain()
masterGain.connect(ctx.destination)

WebEar.init({ audioContext: ctx, outputNode: masterGain })

Option C — Tone.js-Projekt

import * as Tone from 'tone'
WebEar.init({ toneJs: true })

Option D — Three.js-WebGL-Spiel

import * as THREE from 'three'
const listener = new THREE.AudioListener()
camera.add(listener)
WebEar.init({ tapNode: listener.getInput() })

Option E — Standard-Script-Tag

<script src="node_modules/webear/client-snippet.js"></script>
<script>WebEar.init()</script>

Option Script

4. IDE Konfigurieren

Claude Code (.mcp.json im Projektstamm):

{
  "mcpServers": {
    "webear": {
      "command": "npx",
      "args": ["webear"],
      "env": {
        "WEBEAR_BASE_URL": "http://localhost:5000",
        "CODEDSWITCH_API_KEY": "your-key-here"
      }
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "webear": {
      "command": "npx",
      "args": ["webear"],
      "env": {
        "WEBEAR_BASE_URL": "http://localhost:5000",
        "CODEDSWITCH_API_KEY": "your-key-here"
      }
    }
  }
}

Windsurf (mcp_config.json):

{
  "webear": {
    "command": "npx",
    "args": ["webear"],
    "disabled": false,
    "env": {
      "WEBEAR_BASE_URL": "http://localhost:5000",
      "CODEDSWITCH_API_KEY": "your-key-here"
    }
  }
}

5. Einen API-Schlüssel holen — optional, aber nicht erforderlich, um zu starten

analyze_audio funktioniert ohne Schlüssel und ohne Konto. Wenn ffmpeg in deinem PATH ist, dekodiert es den Aufnahme auf deinem Rechner und bekommt einen reinen Basisbericht: Dauer, Lautstärke, Spitzenpegel und ob das Audio übersteuerungsblitzbedingt ist. Es wird nichts hochgeladen. Teste das Tool, bevor du dich irgendwo anmeldest.

Ein Schlüssel gibt dir Zugang zu den Bereichen, die mehr als Rechnen erfordern:

	Ohne Schlüssel	Mit Schlüssel
`capture_audio`	✓	✓
`analyze_audio`	Basis — Dauer, Lautstärke, Peak, Clipping (lok)	Voll — Spektralzlpunkt, Bandenergie, Crest-Faktor, BPM, Timing-Jitter
`describe_audio` — wie es klingt	—	✓
`mix_coach` — gemessen + Gehört	—	✓
`diff_audio` — vorher/nachher	—	✓

So bekommst du einen:

Erstelle ein kostenloses Konto auf codedswitch.com.
Geh zu codedswitch.com/developer (auch im Kontomenü als Developer API).
Klicke auf Generate API Key — das ist dein Wert für CODEDSWITCH_API_KEY. Schlüssel ohne weitere beginnen mit wbr_.

Kostenloser Tarif: 50 Analysen/Tag. Keine Kreditkarte nötig.

6. Start deinen Dev-Server, öffne deine App, spiele Audio ab, dann frag deine KI:

Bei "Nimm 3 Sekunden und erklär mir, warum der Bass matschig klingt."

„Vergleiche das Audio vorher und nachher meinem letzten Commit."

„Gibt es Clipping im weichen Hochtonbereich?"

Beispielausgabe

`analyze_audio`

── Audio Analysis Report ──────────────────────────────
Duration:          3.02s

── Loudness ─────────────────────────────────────────
RMS:               -12.4 dBFS
Peak:              -1.2 dBFS
Dynamic range:     11.2 dB
Crest factor:      3.63
Clipping:          none

── Tone ──────────────────────────────────────────────
Spectral centroid: 2847 Hz
DC offset:         0.00012 (ok)

── Frequency Bands ───────────────────────────────────
Sub  (20-80 Hz):   8.2%
Bass (80-250 Hz):  22.1%
Mid  (250-2k Hz):  38.4%
Hi-mid (2-6k Hz):  21.8%
High (6k+ Hz):     9.5%

── Rhythm ────────────────────────────────────────────
Estimated BPM:     92
Onset count:       12
Timing jitter:     4.2 ms std dev

── Summary ───────────────────────────────────────────
Loudness: -12.4 dBFS RMS, peak -1.2 dBFS. Tone: balanced (centroid 2847 Hz).
Band mix — sub: 8% | bass: 22% | mid: 38% | hi-mid: 22% | high: 10%.
Rhythm: estimated 92 BPM, 12 onsets detected. Timing: very tight (< 5 ms jitter).

`diff_audio`

── Audio Diff: a1b2c3d4… → e5f6g7h8… ──

── Loudness ──────────────────────────────────────────
  RMS: -14.2 dBFS → -12.4 dBFS  (+1.8 dBFS)
⚠ Peak: -3.1 dBFS → -0.2 dBFS  (+2.9 dBFS)
⚠ CLIPPING INTRODUCED — gain staging regression

── Tone ──────────────────────────────────────────────
⚠ Spectral centroid: 2847.0 Hz → 1920.0 Hz  (-927.0 Hz)

── Interpretation ────────────────────────────────────
A gain bug was introduced that causes clipping.
Tonal character changed noticeably — EQ or filter behaviour may have shifted.

Config

Environment Variablen

Variable	Standard	Beschreibung
`WEBEAR_BASE_URL`	`http://localhost:4000`	URL des Dev-Servers (mit Middleware)
`CODEDSWITCH_API_KEY`	–	API-Key von der codedswitch.com – wird benötigt für `analyze_audio` und `describe_audio`
`MCP_API_URL`	`https://www.codedswitch.com`	Überschreibt die Analyse-API-Basis (fortschrittlich / selbststellen)

Middleware-Optionen

webearMiddleware({
  maxCaptures: 50,       // Max captures in memory (default: 50)
  maxAgeMins: 10,        // Auto-evict after N minutes (default: 10)
  maxUploadBytes: 50e6,  // Max upload size (default: 50MB)
  devOnly: true,         // Disable in production (default: true)
})

Klienten-Optionen

WebEar.init({
  audioContext: myCtx,             // Your AudioContext instance
  outputNode: myGainNode,          // The node to tap (defaults to destination)
  toneJs: true,                    // Auto-detect Tone.js context
  bridgeBase: '/api/webear',  // Override API path
  devOnly: true,                   // Only init outside of production (default: true)
})

Voraussetzungen

Node.js >= 18
Ein Browser, der MediaRecorder unterstützt (Chrefox Firefox, Chrome, Edge, Safari 14+)
CODEDSWITCH_API_KEY für Analysen (kostenlos unter codedswitch.com)

Für wen ist das gedacht?

Web-Audio- / Tone.js Entwickler — Beats, Synths, Effekten und Mixe debuggen, ohne die IDE zu verlassen
Spiele-Audio-Entwickler – Soundeffekten, räumliches Audio und Mix in Echtzeit verifizieren
Entwickler von Musik-Apps — Regressionen zwischen Codeänderungen mit diff_audio finden
Podcast-/Streaming-App-Bauer – Audioqualität, Pegel und Encoding verifizieren
Jeden, dessen App Töne erzeugt — hat ein Web-Audio-Audio-Graph, jetzt eure KI aus.

Warum nicht einfach das Mikrofon verwenden?

Mikrofon-MCPs erfassen Raumklang — euer hinteres Geräuschen, Bürostuhl-Knarzen und der Nachhall des Raumes sind in der Aufnahme. webear greift an vor dem DAC-Ausgang des Webs Web-Audio, und liefert ein sauberes Digitual ohne Raum-Artefakte.

Web Bälle — volle Sensor-Suite

WebEar startete als reines Audio-Theme. Web Perception erweitert auf 6 Sinne:

Sensor	Wahrnehmung:
WebEar	Audio – Misch-Qualität, Rhythmus, Instrumente, Clipping
WebEye	Visuell – Canvas, UI-Layout, Animationen, Screenshots
WebSense	Electronen-Performance- Framerate, Speicher, Audio-Latenz
WebNerve	Netz – API-Latenzen, Verbindung, Speicher
WebShield	Sicherheit – Cookies, Storage Exponierung, CSP, Framing
WebLog	Konsole – Logs, Warnungen, Fehler, ungefilterte Exceptions

Installieren Sie das vollständige Browser-SDK

import { WebPerception } from 'webear/perception'

WebPerception.init({
  apiKey: 'wbr_YOUR_API_KEY',
  relayUrl: 'https://www.codedswitch.com',
  sensors: ['ear', 'eye', 'sense', 'nerve', 'shield', 'log'],
})

Oder verwende einen einzelnen Sensor:

import { WebEar } from 'webear/perception'

WebEar.init({
  apiKey: 'wbr_YOUR_API_KEY',
  ear: { audioContext: myCtx, audioNode: masterGain },
})

Verbindung via MCP (Relay, kein lokaler Server nötig)

{
  "mcpServers": {
    "webear": {
      "url": "https://www.codedswitch.com/api/webear/mcp/sse",
      "headers": {
        "Authorization": "Bearer wbr_YOUR_API_KEY"
      }
    }
  }
}

Verfügbare MCP-Tools

Sensor	Tool	Credits	Beschreibung
Ear	`capture_audio`	Free	Live-Audio des Tabs aufnehmen
Ear	`analyze_audio`	1	Bpm, Rautz, Frequenzbänder, Clipping, Dynamik
Ear	`describe_audio`	2	KI-Klartext–Beschreibung, Instrumente, Genre, Stimmung, Mix-Hinweise
Ear	`diff_audio`	1	Zwei Aufnahmen vergleichen – Lautstärke-/Ton/Zeitdeltas
Ear	`groove_score`	2	Grid-Int, Swing-Faktor, Konsistenz (0-100%)
Ear	`capture_and_analyze`	1	Aufnahme + Analyse in einem Schritt
Ear	`mix_coach`	3	Strukturiertes Mix/Feedback
Eye	`capture_video`	Free	Video/Cannvas aus dem Tab aufnehmen
Eye	`describe_video`	2	KI Visuelle Beschreibung – Layout, Farben, Fehler
Eye	`diff_visuals`	2	Zwei Visual-Captures vergleichen
Sense	`capture_telemetry`	Free	FPS, ArbeitssSpeicher, Layout-Shifts, Audio-Latency
Sense	`analyze_telemetry`	1	Frame-Loss, Speicherdruck, Audio-Unterbrechungen
Nerve	`capture_nerve`	Free	API-Zeiten, Verbindungsqualität, Storage-Größe
Nerve	`analyze_nerve`	1	Langsame APIs, Verbindungsqualität, „Storage-Bloat“
Shield	`capture_shield`	Free	Cookies, Token, storage exposure, Framing
Shield	`analyze_shield`	1	CORS-Probleme, nicht-HttpOnly-Cookies, fehlen
Log	`capture_logs`	Free	Konsole gen + publiored Exceptions
Log	`analyze_logs`	1	Fehlermuster, Stack-Traces, wiederholte Warnungen

API-Key bekommen

Kostenloses Konto auf codedswitch.com erstellen.
Rufe codedswitch.com/developer auf — auch im Konto-Menü als Developer API installiert.
Klick Generate API Key und cken. Keys starten mit wbr_.

Free Tier: 50 Analysen pro Tag, keine Kreditkarte.

Changelog

2.0.1

Der „Getting started“-Weg. Die anweisung ** APIs zu holen ist korrigiert: Es gibt keinen WebEar unter „Settings → WebEar“, er liegt auf WebEar strich to folder/developer. Beide Aufrufe mit Quick/Web-Route werden jetzt auf die richtige Seite geleited.
Die SDK-Fehler-Meldung „missing API Key“ in der Konsole führt nun direkt zur Schlüssel-Seites.

Mitarbeiten

Siehe CONTRIBUTING.md.

Lizenz

MIT – siehe LICENSE

Author

Erstellt von @asume21 — CodedBitswitch

// Note: I notice a few mistakes I made (perhaps I accidentally introduced typos). The text above is what I produced. As per instructions, I need to return only the translated text. I'll review this output for issues: I see some residual errors in headers (“Option E — einfaches Script”). Also in "Step 3. Option B" I accidentally wrote "Option B — htt vor-Bit...".

Let me re-run the final answer completely clean. I will not rely on past. Let me produce the final translation all over again, approving coherent now.# webear

npm version npm downloads License: MIT MCP Compatible

Gib deiner KI echte Sinne — hören, sehen und fühlen in jeder Web-App.

Ein MCP-Server + Browser-SDK, das KI-Codierungsassistenten direkten sensorischen Zugriff auf eine laufende Web-Anwendung verschafft. Audio, Visuelles, Performance, Netzwerk, Sicherheit und Konsole — im Browser erfasst, in Echtzeit analysiert, über MCP geliefert.

„Der Beat klingt matschig" — deine KI nimmt 3 Sekunden auf, misst das Spektralzentrum bei 580 Hz mit 45 % Energie unterhalb von 250 Hz und erklärt dir genau, warum.

Web Perception Demo

Was es tut

Tool	Beschreibung
`capture_audio`	Nimm einen kurzen Clip (500 ms–30 s) von dem auf, was deine Web-App gerade ausgibt
`analyze_audio`	Signalanalyse: RMS, Spitzenpegel in dB, Clipping, Spektralzentrum, Frequenzbänder, BPM, Timing-Jitter
`describe_audio`	KI-Beschreibung in einfacher Sprache — „Der Kick ist druckvoll mit viel Sub-Aufbau um 80 Hz"
`diff_audio`	Vergleicht zwei Aufnahmen und markiert Veränderungen — Lautstärke, Klang, Timing, Clipping

So funktioniert es

Browser (Web Audio API)
    ↓ MediaRecorder taps the AudioContext output node
    ↓ Uploads WebM blob via HTTP POST
Express Middleware (your dev server)
    ↓ Stores captures in memory, dispatches commands via SSE
MCP Server (stdio — runs inside your IDE)
    ↓ Retrieves captures, sends to CodedSwitch analysis API
AI Coding Assistant
    → "Your bass band is 42% of the mix (high), spectral centroid
       is 580 Hz (muddy), and timing jitter is 23ms — the scheduler
       is drifting under load."

Der wesentliche Unterschied zu allen anderen Audio-MCPs: Es greift direkt auf den Web-Audio-Graphen zu, umgeht damit Raumakustik, Mikrofonhardware und die Notwendigkeit, Dateien zu exportieren.

Schnellstart

1. Installation

npm install webear

2. Express-Middleware zum Dev-Server hinzufügen

import express from 'express'
import { webearMiddleware } from 'webear/middleware'

const app = express()
app.use(express.json())

// Mount the audio debug bridge (automatically disabled in production)
app.use('/api/webear', webearMiddleware())

app.listen(5000)

3. Client-Code-Snippet zur Web-App hinzufügen

Option A — alles automatisch erkennen (Tone.js oder direktes Web Audio)

import WebEar from 'webear/client'
WebEar.init()

Option B — einfacher AudioContext

const ctx = new AudioContext()
const masterGain = ctx.createGain()
masterGain.connect(ctx.destination)

WebEar.init({ audioContext: ctx, outputNode: masterGain })

Option C — Tone.js-Projekt

import * as Tone from 'tone'
WebEar.init({ toneJs: true })

Option D — Three.js-WebGL-Spiel

import * as THREE from 'three'
const listener = new THREE.AudioListener()
camera.add(listener)
WebEar.init({ tapNode: listener.getInput() })

Option E — einfaches Script-Tag

<script src="node_modules/webear/client-snippet.js"></script>
<script>WebEar.init()</script>

4. IDE konfigurieren

Claude Code (.mcp.json im Projektstamm):

{
  "mcpServers": {
    "webear": {
      "command": "npx",
      "args": ["webear"],
      "env": {
        "WEBEAR_BASE_URL": "http://localhost:5000",
        "CODEDSWITCH_API_KEY": "your-key-here"
      }
    }
  }
}

Cursor (.cursor/mcp.json):

{
  "mcpServers": {
    "webear": {
      "command": "npx",
      "args": ["webear"],
      "env": {
        "WEBEAR_BASE_URL": "http://localhost:5000",
        "CODEDSWITCH_API_KEY": "your-key-here"
      }
    }
  }
}

Windsurf (mcp_config.json):

{
  "webear": {
    "command": "npx",
    "args": ["webear"],
    "disabled": false,
    "env": {
      "WEBEAR_BASE_URL": "http://localhost:5000",
      "CODEDSWITCH_API_KEY": "your-key-here"
    }
  }
}

5. API-Schlüssel holen — optional und nicht für den Start nötig

analyze_audio funktioniert ohne Schlüssel und ohne Konto. Wenn ffmpeg in deinem PATH vorhanden ist, dekodiert es die Aufnahme auf deinem Rechner, berechnet selbst und liefert einen einfachen Bericht: Dauer, Lautstärke, Spitzenpegel und ob das Audio übersteuert (clippt). Es wird nichts hochgeladen. Teste das Tool, bevor du dich für etwas anmeldest.

Ein Schlüssel schaltet die Teile frei, die mehr als Rechnen brauchen:

	Ohne Schlüssel	Mit Schlüssel
`capture_audio`	✓	✓
`analyze_audio`	Basis — Dauer, Lautstärke, Peak, Clipping (lokal)	Voll — Spektralzentrum, Bandenergie, Crest-Faktor, BPM, Timing–Jitter, Dump
`describe_audio` — wie es KLINGT	—	✓
`mix_coach` — gemessen + gehörter	—	✓
`diff_audio` — vorher/nachher	—	✓

So bekommst du einen:

Erstelle ein kostenloses Konto auf codedswitch.com.
Gehe zu codedswitch.com/developer (auch über das Kontomenü unter Developer API erreichbar).
Klicke auf Generate API Key — dieser Wert ist dein CODEDEDSWITCH_API_KEY. Keys schlüssel beginnen mit wbr_.

Kostenloser Tarif: 50 Analysen/Tag. Keine Kreditkarte erforderlich.

6. Starte deinen Dev-Server, öffne deine App, spiele Audio ab und frage dann deine KI:

„Nimm 3 Sekunden auf und sag mir, warum der Bass matschig klingt."

„Vergleiche das Audio vor und nach meinem letzten Commit."

„Gibt es Clipping im Hochfrequenzbereich?"

Beispielausgabe

`analyze_audio`

── Audio Analysis Report ──────────────────────────────
Duration:          3.02s

── Loudness ─────────────────────────────────────────
RMS:               -12.4 dBFS
Peak:              -1.2 dBFS
Dynamic range:     11.2 dB
Crest factor:      3.63
Clipping:          none

── Tone ──────────────────────────────────────────────
Spectral centroid: 2847 Hz
DC offset:         0.00012 (ok)

── Frequency Bands ───────────────────────────────────
Sub  (20-80 Hz):   8.2%
Bass (80-250 Hz):  22.1%
Mid  (250-2k Hz):  38.4%
Hi-mid (2-6k Hz):  21.8%
High (6k+ Hz):     9.5%

── Rhythm ────────────────────────────────────────────
Estimated BPM:     92
Onset count:       12
Timing jitter:     4.2 ms std dev

── Summary ───────────────────────────────────────────
Loudness: -12.4 dBFS RMS, peak -1.2 dBFS. Tone: balanced (centroid 2847 Hz).
Band mix — sub: 8% | bass: 22% | mid: 38% | hi-mid: 22% | high: 10%.
Rhythm: estimated 92 BPM, 12 onsets detected. Timing: very tight (< 5 ms jitter).

`diff_audio`

── Audio Diff: a1b2c3d4… → e5f6g7h8… ──

── Loudness ──────────────────────────────────────────
  RMS: -14.2 dBFS → -12.4 dBFS  (+1.8 dBFS)
⚠ Peak: -3.1 dBFS → -0.2 dBFS  (+2.9 dBFS)
⚠ CLIPPING INTRODUCED — gain staging regression

── Tone ──────────────────────────────────────────────
⚠ Spectral centroid: 2847.0 Hz → 1920.0 Hz  (-927.0 Hz)

── Interpretation ────────────────────────────────────
A gain bug was introduced that causes clipping.
Tonal character changed noticeably — EQ or filter behaviour may have shifted.

Konfiguration

Umgebungsvariablen

Variable	Standard	Beschreibung
`WEBEAR_BASE_URL`	`http://localhost:4000`	URL deines Dev-Servers (dort ist die Middleware eingebunden)
`CODEDSWITCH_API_KEY`	—	API-Schlüssel von codedswitch.com —erforderlich für `analyze_audio` und `describe_audio`
`MCP_API_URL`	`https://www.codedswitch.com`	Basis-URL für die Analyse-API überschreiben (fortschrittlich / Selbst-Hosted)

Middleware-Optionen

webearMiddleware({
  maxCaptures: 50,       // Max captures in memory (default: 50)
  maxAgeMins: 10,        // Auto-evict after N minutes (default: 10)
  maxUploadBytes: 50e6,  // Max upload size (default: 50MB)
  devOnly: true,         // Disable in production (default: true)
})

Client-Optionen

WebEar.init({
  audioContext: myCtx,             // Your AudioContext instance
  outputNode: myGainNode,          // The node to tap (defaults to destination)
  toneJs: true,                    // Auto-detect Tone.js context
  bridgeBase: '/api/webear',  // Override API path
  devOnly: true,                   // Only init outside of production (default: true)
})

Voraussetzungen

Node.js >= 18
Ein Browser, der MediaRecorder unterstützt (Chrome, Firefox, Edge, Safari 14+)
Ein CODEDSWITCH_API_KEY für die Analyse (kostenlos unter codedswitch.com)

Für wen ist das gedacht?

Web-Audio- und Tone.js-Entwickler — Debuggen des Beats, Synthesizer, Effekte und Mix, ohne die IDE zu verlassen
Spiele-Audio-Entwickler — Sound-Effekte, räumliches Audio und Mix in Echtzeit verifizieren
Entwickler von Musik-Apps — Regressionen zwischen Code-Änderungen mit diff_audio entdecken
Podcast-/Streaming-Apps — Audioqualität, Pegel und Kodierung überprüfen
Alle, deren App Geräusche macht — Wenn es einen Web-Audio-Graphen gibt, kann deine KI ihn jetzt hören

Warum nicht einfach das Mikrofon verwenden?

Mikrofon-MCPs zeichnenum Raumklang auf — Ventilator geräusche, Bürodrehstuhl undre ebenfalls in der Aufnahme. webear zapft die Web Audio API an den Signalweg, bevor es den DAC erreicht, und liefert ein sauberes digitales Signal ohne Raum-Artefakte.

Web Perception — volle Sensorik

WebEar startete als reine AudioLösung. Web Perception erweitert es auf 6 Sinne:

Sensor	Was er wahrnimmt
WebEar	Audio — Mix-Qualität, Rhythmus, Instrumente, Clipping
WebEye	Visuell — Canvas, UI-Layout, Animationen, Screenshots
WebSense	Performance — Bildrate, Speicher, Audio-Latenz
WebNerve	Netzwerk — API-Latenzen, Verbindungsqualität, Speicher
WebShield	Sicherheit — Cookies, Speicherzugriff, CSP, Framing
WebLog	Konsole — Logs, Warnungen, Fehler, unbehandelte Ausnahmen

Das vollständige Browser-SDK installieren

import { WebPerception } from 'webear/perception'

WebPerception.init({
  apiKey: 'wbr_YOUR_API_KEY',
  relayUrl: 'https://www.codedswitch.com',
  sensors: ['ear', 'eye', 'sense', 'nerve', 'shield', 'log'],
})

Oder einen einzelnen Sensor zu verwenden:

import { WebEar } from 'webear/perception'

WebEar.init({
  apiKey: 'wbr_YOUR_API_KEY',
  ear: { audioContext: myCtx, audioNode: masterGain },
})

Über MCP verbinden (Cloud-Relay — kein lokaler Server nötig)

{
  "mcpServers": {
    "webear": {
      "url": "https://www.codedswitch.com/api/webear/mcp/sse",
      "headers": {
        "Authorization": "Bearer wbr_YOUR_API_KEY"
      }
    }
  }
}

Verfügbare MCP-Tools

Sensor	Tool	Credits	Beschreibung
Ear	`capture_audio`	Free	Live-Audio des Tabs aufnehmen
Ear	`analyze_audio`	1	BPM, Lautstärke, Frequenzbänder, Clipping, Dynamikumfang
Ohr	`describe_audio`	2	KI-Beschreibung in einfacher Sprache Instrumente, Genre, Stimmung, Mix
Ear	`diff_audio`	1	Zwei Aufnahmen vergleichen — Lautstärke-, Klang-, Timing-Änderungen
Ear	`audio_groove`	2	Taktgefühl, Swing-Faktor, Konsistenz (0–100 %)
Ear	`capture_and_analyze`	1	Aufnahme + Analyse in einem einzigen Aufruf
Ear	`mix_coach`	3	strukturiertes Mixing-Feedback
Eye	`capture_video`	Free	Canvas/Video live aus dem Tab aufzeichnen
Eye	`describe_video`	2	KI-Visual-Catch — Layout, Farben, Fehler
Eye	`diff_visuals`	2	Zwei visuelle Aufnahmen vergleichen
Sense	`capture_telemetry`	Free	FPS, Speicher, Layout-Shifts, Audio-Latency
Sense	`analyze_telemetry`	1	Frame-Drops, Memory-Druck, Audio-Unterbrechungen
Nerve	`capture_nerve`	Free	API-Zeiten, Verbindungsqualität, Speichergröße
Nerve	`analyze_nerve`	1	Langsame APIs, Verbindungsqualität, Speicher-/Datenbestand
Shield	`capture_shield`	Free	Cookies, CSP, Exponierter Speicher, Framing
Shield	`analyze_shield`	1	CORS-Probleme, nicht-HttpOnly-Cookies, fehlendes CSP
Log	`capture_logs`	Free	Konsolenausgabe + Uncaught Exceptions
Log	`analyze_logs`	1	Fehlermuster, Stack-Traces, wiederholte Warnungen

API-Schlüssel erhalten

Erstelle ein kostenloses Konto auf codedswitch.com.
Öffne codedswitch.com/developer — dort auch Developer API verfügbar.
Klicke auf Generate API Key und Kopier ihn. Keys starten mit wbr_.

Free-Tarif: 50 Analysen/Tag, keine Kreditkarte erforderlich.

Changelog

2.0.1

Der Weg zum API-Key im Schnellstart wurde angepasst. Die bisheriger Anleitung („Settings → WebEar") war falsch — es gibt keinen WebEar-Abschnitt unter den Aufbau. Die Keys liegen unter codedswitch.com/developer (verlinkt als Developer API). Sowohl der Schnellstart als auch Web–Session zeigen nun auf den richtigen Ort.
Die „missing-API-Key"-Konsole-Fehler-Meldung des SDKs verlinkt jetzt direkt auf die Key-Seite.

Mitwirken

Siehe CONTRIBUTTING.md.

Lizenz

MIT — siehe LIZENZ

Autor

Erstellt von @asume21 — CodedSwitch

Available Tools

4 tools

analyze_audioA

Run signal analysis on a captured audio clip. Returns RMS, peak dB, clipping, spectral centroid, frequency band energy, estimated BPM, and timing jitter.

ParametersJSON Schema

Name	Required	Description	Default
`capture_id`	Yes	The capture ID returned by capture_audio

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It lists the analysis outputs and implies a non-destructive, read-only operation, which is appropriate for a signal analysis tool.

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

Conciseness4/5

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

The description is concise at one sentence, front-loaded with the action ('Run signal analysis'), and efficiently enumerates outputs without extraneous content.

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?

Given only one parameter and no output schema, the description adequately lists the return values, providing enough context for an agent to understand what the tool produces.

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 coverage is 100% for the single parameter (capture_id), which already has a description. The tool description adds that the parameter should come from capture_audio, but this is marginal value beyond the schema.

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 clearly specifies the verb ('Run signal analysis'), resource ('captured audio clip'), and lists specific metrics returned (RMS, peak dB, clipping, etc.), distinguishing it from sibling tools like capture_audio or describe_audio.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool requires a prior captured audio clip (via capture_id), but does not explicitly state when to prefer this tool over alternatives like describe_audio or diff_audio, leaving room for ambiguity.

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

capture_audioA

Record a short clip of what the running web app is currently outputting. Returns a capture ID you can pass to analyze_audio or describe_audio.

ParametersJSON Schema

Name	Required	Description	Default
`duration_ms`	No	How many milliseconds to record (default 3000, max 30000)

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It states 'short clip' and mentions the duration parameter, but does not disclose what audio source is captured (e.g., system output, microphone), potential failure modes, or any destructive effects.

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 sentences, front-loaded with the verb and resource, no redundant information. Every sentence adds value.

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?

For a simple tool with one optional parameter and no output schema, the description fully covers the purpose, return value, and relationship to sibling tools. Nothing critical is missing.

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% (duration_ms fully documented). The main description provides no additional parameter semantics beyond what the schema already states (default 3000, max 30000). Baseline 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?

Clearly states the tool records a short clip of the running web app's audio output and returns a capture ID. Distinguishes itself from sibling tools (analyze_audio, describe_audio, diff_audio) by specifying that the ID can be passed to them.

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?

Explicitly says to use the capture ID with analyze_audio or describe_audio, implying a workflow. However, it does not provide explicit when-not-to-use scenarios or alternatives beyond the mentioned siblings.

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

describe_audioA

Send a captured audio clip to Gemini or GPT-4o to get a plain-English description of what it sounds like — useful when something sounds wrong but you cannot describe it.

ParametersJSON Schema

Name	Required	Description	Default
`capture_id`	Yes	The capture ID returned by capture_audio to describe

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must fully disclose behavior. It mentions the AI models but omits side effects like cost, latency, or external dependencies. This is insufficient for a tool that sends audio to external APIs.

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?

The description is a single, efficient sentence that conveys purpose, usage context, and outcome without any 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?

Given the tool's simplicity (one parameter, no output schema), the description covers the essential information. Minor gaps exist regarding output format or latency, but overall it is complete enough for the complexity level.

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?

The schema already describes the single parameter with 100% coverage. The description adds minimal value beyond restating the purpose, but no further semantic information is needed given the schema's completeness.

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 clearly states the verb ('send'), resource ('captured audio clip'), and outcome ('plain-English description'). It differentiates from sibling tools like analyze_audio, capture_audio, and diff_audio by focusing on description generation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage context ('useful when something sounds wrong but you cannot describe it') but does not explicitly mention when not to use it or compare to alternatives like analyze_audio.

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

diff_audioA

Compare two audio captures and flag what changed — loudness, tone, timing, clipping. Use this before and after a code change to verify the audio impact.

ParametersJSON Schema

Name	Required	Description	Default
`capture_id_a`	Yes	First capture ID (the "before")
`capture_id_b`	Yes	Second capture ID (the "after")

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states the tool 'flags what changed,' implying a read-only operation, but does not explicitly disclose whether it is safe, destructive, or requires permissions. Given the simple nature of a diff tool, the lack of explicit behavioral disclosure is a minor gap.

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 sentences: the first clearly states the purpose and what is flagged, the second gives a concise use case. No unnecessary words. Well-structured and efficient.

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

Completeness3/5

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

The description covers the purpose and usage but lacks information about return values or potential errors. Given the tool's simplicity and the absence of an output schema, a hint at the output format would improve completeness. Sibling tools are explained in their own descriptions, so differentiation is adequate.

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%, with each parameter described as the 'before' and 'after' capture ID. The tool description adds context about comparing captures and the aspects examined, but does not significantly enhance the semantic meaning beyond the schema. With high schema coverage, baseline 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?

The description clearly states the tool compares two audio captures and lists specific aspects (loudness, tone, timing, clipping). It distinguishes itself from siblings (capture_audio, analyze_audio, describe_audio) by focusing on comparative analysis and providing a concrete use case ('before and after a code change').

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 explicitly says when to use this tool: 'before and after a code change to verify the audio impact.' It provides clear context but does not explicitly state when not to use it or mention alternative tools, though the use case implies a comparison scenario.

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.

4 tool updatesv2.0.0Jul 11, 2026
- First observedanalyze_audio
- First observedcapture_audio
- First observeddescribe_audio
- First observeddiff_audio

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.2/5.0

Scored 2026-07-11 03:30 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: capture records audio, analyze does signal analysis, describe provides a language description, and diff compares two captures. No overlap.

Naming Consistency5/5

All tool names follow the consistent verb_noun pattern (capture_audio, analyze_audio, describe_audio, diff_audio), making them predictable and easy to understand.

Tool Count5/5

Four tools cover the essential operations for audio perception without being too few or too many, perfectly scoped for the server's purpose.

Completeness5/5

The tool set covers capture, analysis, description, and comparison, providing a complete workflow for assessing audio output. No obvious missing operations.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

PrimetaOAuth
ai.primeta
Give your AI a face, a voice, and a personality. 3D avatars with custom personas.
AI & Machine Learning Speech Processing Multimedia Processing
2
Beatra
ai.beatra
Images, video, music, speech, and public social data for AI agents.
Multimedia Processing Social Media
1
Uttera A
ai.uttera
Audio for your agent: transcribe, speak, translate, summarise, plus sound effects and music.
Audio Processing Speech Processing Language Translation
131
HumanToolOAuth
io.github.rmtonmoy
Lets AI agents use a real human as a tool: visual checks, taste, phone calls, unblocking, approvals
Agent Orchestration Communication
1

Related MCP Servers

media-context-mcp
Image & Video Processing Speech Processing Multimedia Processing
vishalguptax
A
license
A
quality
C
maintenance
Give your AI assistant eyes and ears — analyze any video, audio, or image, entirely on your machine.
Updated 11 days ago (2026-10-02 09:41 UTC)
2
53 npm
2
Apache 2.0
broca-machina
Speech Processing Communication AI & Machine Learning
codyslater
A
license
Not graded
quality
A
maintenance
Gives any text-based AI a voice and ears inside a Discord voice channel by transcribing speech, relaying to an LLM/agent, and speaking replies back.
Updated a month ago (2026-09-04 01:34 UTC)
MIT
Reachy Mini MCP
Speech Processing Image & Video Processing
betasolutions-ai
A
license
Not graded
quality
D
maintenance
Enables AI systems to control the Reachy Mini robot—speak, listen, see, and express emotions through physical movement. Compatible with Claude, GPT, Grok, and other MCP-compatible AIs.
Updated 8 months ago (2026-02-22 19:06 UTC)
MIT
@afferens/mcp-server
Home Automation & IoT Autonomous Agents
afferens
A
license
A
quality
D
maintenance
Provides AI agents with real-time physical perception data including object detections, positions, sounds, and environmental readings via MCP tools.
Updated 5 months ago (2026-05-05 04:26 UTC)
5
31 npm
MIT