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

AI에게 진짜 감각을 부여하세요 — 모든 웹 앱을 듣고, 보고, 느끼게 하세요.

AI 코딩 어시스턴트에게 라이브 웹 애플리케이션에 대한 직접적인 감각적 접근을 제공하는 MCP 서버 + 브라우저 SDK입니다. 오디오, 시각, 성능, 네트워크, 보안, 콘솔 — 브라우저에서 캡처하고, 실시간으로 분석하며, MCP를 통해 전달합니다.

"비트가 탁하게 들려요" → AI가 3초를 캡처하고, 스펙트럼 중심이 580 Hz이고 250 Hz 이하에 에너지의 45%가 있음을 측정한 다음, 정확히 그 이유를 알려줍니다.

AI Web Perception Demo

기능

도구	설명
`capture_audio`	웹 앱이 지금 출력하는 소리를 짧은 클립(500ms–30s)으로 녹음합니다
`analyze_audio`	신호 분석: RMS, 피크 dB, 클리핑, 스펙트럼 중심, 주파수 대역, BPM, 타이밍 지터
`describe_audio`	평문 영어 AI 설명 — "킥이 80 Hz 부근에서 무거운 서브 축적과 함께 웅웅거립니다"
`diff_audio`	두 캡처를 비교하고 변경된 사항을 플래그합니다 — 음량, 톤, 타이밍, 클리핑

Related MCP server: broca-machina

작동 방식

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."

다른 모든 오디오 MCP와의 핵심 차이점: Web Audio 그래프를 직접 연결하여, 실내 음향, 마이크 하드웨어, 파일 내보내기의 필요성을 우회합니다.

빠른 시작

1. 설치

npm install webear

2. 개발 서버에 Express 미들웨어 추가

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. 웹 앱에 클라이언트 스니펫 추가

옵션 A — 모든 것을 자동 감지 (Tone.js 또는 순수 Web Audio)

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

옵션 B — 명시적 AudioContext

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

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

옵션 C — Tone.js 프로젝트

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

옵션 D — Three.js WebGL 게임

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

옵션 E — 일반 script 태그

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

4. IDE 구성

Claude Code (프로젝트 루트의 .mcp.json):

{
  "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 키 받기 — 선택 사항이며, 시작할 때는 필요 없습니다

analyze_audio는 키나 계정 없이 작동합니다. ffmpeg가 PATH에 있으면, 캡처를 사용자 머신에서 디코딩하고 분석하여 기본 보고서를 반환합니다: 재생 시간, 음량, 피크 레벨, 오디오 클리핑 여부. 아무것도 업로드되지 않습니다. 가입 전에 먼저 도구를 사용해 보세요.

키가 있으면 산술 이상이 필요한 부분이 잠금 해제됩니다:

	키 없음	키 있음
`capture_audio`	✓	✓
`analyze_audio`	기본 — 재생 시간, 음량, 피크, 클리핑 (로컬)	전체 — 스펙트럼 중심, 대역 에너지, 크레스트 팩터, BPM, 타이밍 지터
`describe_audio` — 소리가 어떤지	—	✓
`mix_coach` — 측정 + 청취	—	✓
`diff_audio` — 전후 비교	—	✓

키를 받으려면:

**codedswitch.com**에서 무료 계정을 만드세요.
**codedswitch.com/developer**로 이동하세요 (계정 메뉴의 Developer API에도 있습니다).
Generate API Key를 클릭하세요 — 해당 값이 CODEDSWITCH_API_KEY입니다. 키는 wbr_로 시작합니다.

무료 티어: 하루 50회 분석. 신용카드 불필요.

6. 개발 서버를 시작하고, 앱을 열고, 오디오를 재생한 다음 AI에게 물어보세요:

"3초 캡처해서 베이스가 왜 탁하게 들리는지 알려줘."

"마지막 커밋 전후의 오디오를 비교해줘."

"고주파 영역에 클리핑이 있나?"

예시 출력

`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.

구성

환경 변수

변수	기본값	설명
`WEBEAR_BASE_URL`	`http://localhost:4000`	개발 서버의 URL (미들웨어가 마운트된 곳)
`CODEDSWITCH_API_KEY`	—	codedswitch.com의 API 키 — `analyze_audio` 및 `describe_audio`에 필요
`MCP_API_URL`	`https://www.codedswitch.com`	분석 API 기본 URL 재정의 (고급 / 자체 호스팅)

미들웨어 옵션

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)
})

클라이언트 옵션

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)
})

요구 사항

Node.js >= 18
MediaRecorder를 지원하는 브라우저 (Chrome, Firefox, Edge, Safari 14+)
분석용 CODEDSWITCH_API_KEY (codedswitch.com에서 무료)

대상 사용자

Web Audio / Tone.js 개발자 — IDE를 벗어나지 않고 비트, 신디사이저, 이펙트, 믹싱 디버깅
게임 오디오 개발자 — 사운드 이펙트, 공간 오디오, 믹싱을 실시간으로 검증
음악 앱 빌더 — diff_audio로 코드 변경 간 회귀 감지
팟캐스트 / 스트리밍 앱 — 오디오 품질, 레벨, 인코딩 검증
소리를 만드는 앱을 만드는 모든 사람 — Web Audio 그래프가 있다면 AI가 이제 들을 수 있습니다

마이크를 사용하지 않는 이유는?

마이크 MCP는 방음(room sound)을 캡처합니다 — 팬 소음, 의자 삐걱임, 방의 잔향이 모두 녹음에 포함됩니다. webear는 DAC에 도달하기 전에 Web Audio API를 연결하여, 방의 인공물이 없는 깨끗한 디지털 신호를 제공합니다.

Web Perception — 전체 센서 제품군

WebEar는 오디오 전용으로 시작했습니다. Web Perception은 이를 6가지 감각으로 확장합니다:

센서	인지하는 것
WebEar	오디오 — 믹스 품질, 리듬, 악기, 클리핑
WebEye	시각 — 캔버스, UI 레이아웃, 애니메이션, 스크린샷
WebSense	성능 — 프레임 레이트, 메모리, 오디오 지연
WebNerve	네트워크 — API 지연, 연결 품질, 저장소
WebShield	보안 — 쿠키, 저장소 노출, CSP, 프레이밍
WebLog	콘솔 — 로그, 경고, 오류, 처리되지 않은 예외

전체 브라우저 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'],
})

또는 단일 센서 사용:

import { WebEar } from 'webear/perception'

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

MCP로 연결 (호스팅 릴레이 — 로컬 서버 불필요)

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

사용 가능한 MCP 도구

센서	도구	크레딧	설명
Ear	`capture_audio`	무료	라이브 탭 오디오 녹음
Ear	`analyze_audio`	1	BPM, 음량, 주파수 대역, 클리핑, 다이내믹 레인지
Ear	`describe_audio`	2	AI 평문 영어 설명 — 악기, 장르, 분위기, 믹스 노트
Ear	`diff_audio`	1	두 캡처 비교 — 음량, 톤, 타이밍 델타
Ear	`groove_score`	2	그리드 정렬, 스윙 팩터, 일관성 (0–100%)
Ear	`capture_and_analyze`	1	캡처 + 분석을 한 번에
Ear	`mix_coach`	3	구조화된 믹싱 피드백
Eye	`capture_video`	무료	탭에서 캔버스/비디오 녹화
Eye	`describe_video`	2	AI 시각 설명 — 레이아웃, 색상, 버그
Eye	`diff_visuals`	2	두 시각 캡처 비교
Sense	`capture_telemetry`	무료	FPS, 메모리, 레이아웃 시프트, 오디오 지연
Sense	`analyze_telemetry`	1	프레임 드롭, 메모리 압박, 오디오 언더런
Nerve	`capture_nerve`	무료	API 타이밍, 연결 품질, 저장소 크기
Nerve	`analyze_nerve`	1	느린 API, 연결 품질, 저장소 비대
Shield	`capture_shield`	무료	쿠키, CSP, 저장소 노출, 프레이밍
Shield	`analyze_shield`	1	CORS 문제, 비-HttpOnly 쿠키, CSP 누락
Log	`capture_logs`	무료	콘솔 출력 + 처리되지 않은 예외
Log	`analyze_logs`	1	오류 패턴, 스택 트레이스, 반복 경고

API 키 받기

**codedswitch.com**에서 무료 계정을 만드세요.
**codedswitch.com/developer**를 여세요 — 계정 메뉴의 Developer API로도 연결됩니다.
Generate API Key를 클릭하고 복사하세요. 키는 wbr_로 시작합니다.

무료 티어: 하루 50회 분석, 신용카드 불필요.

변경 로그

2.0.1

API 키 시작 경로를 수정했습니다. 이전 안내 ("Settings → WebEar")는 잘못되었습니다 — Settings 아래에 WebEar 섹션은 없습니다. 키는 **codedswitch.com/developer**에 있습니다 (계정 메뉴의 Developer API로 연결). 빠른 시작과 Web Perception 섹션 모두 이제 올바른 위치를 가리킵니다.
SDK의 "API 키 누락" 콘솔 오류가 이제 키 페이지로 직접 연결됩니다.

기여

CONTRIBUTING.md를 참조하세요.

라이선스

MIT — LICENSE 참조

작성자

@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