What can you do with this server?

The Streamfog MCP server enables AI assistants and scripts to control AR lenses, face filters, and Vtuber avatars in live streams by bridging commands to Streamer.bot. You can: * Activate AR lenses or face filters using streamfog_set_lens, specifying a lens identifier (e.g., beauty_smooth, cyber_helmet) from the local lenses.json mapping. * Clear all effects via streamfog_clear_effects to remove active AR assets and return to a clean camera feed. * Toggle Vtuber avatars with streamfog_toggle_avatar to turn the avatar overlay on or off (activates the default avatar if none is active). * List available lenses using streamfog_list_lenses, which retrieves all configured lenses and their action names, with an option to reload from disk. * Check bridge connection status via streamfog_status, showing connectivity to Streamer.bot, loaded lens count, and recent errors. * Access a REST API for programmatic control, health checks, lens management, and logs. * Use a web dashboard at port 10995 for manual interaction, including lens selection, status KPIs, and local LLM chat. * Run the server in dual mode (stdio or HTTP) to integrate with MCP clients like Claude or Cursor.

Which integrations are available for this server?

Allows controlling AR lenses, face filters, Vtuber avatars, and effects in OBS Studio via Streamfog and Streamer.bot during live broadcasts. Enables AI agents to trigger lens switches, avatar toggles, and effect clears on Twitch streams using chat events and channel points.

How do I use Streamfog MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Streamfog MCP switch to the cyber helmet lens" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Streamfog MCP

by sandraschi

Overview Schema Related Servers Score Discussions

Local

Streamfog MCP

📖 Installation Guide — quick start, manual setup, and troubleshooting 📖 Docs — Configuration · Tools · Troubleshooting · Development 🤖 llms-full.txt — full LLM-readable documentation

AI-driven AR lens orchestrator for live OBS streams. Control Streamfog face filters, AR effects, and Vtuber avatars through MCP tools via the local Streamer.bot WebSocket bridge. Your AI assistant becomes a stream producer.

What is Streamfog?

Streamfog is a Windows desktop app (https://streamfog.com) that streamers use to put AR effects on their face during live broadcasts — face filters ("beauty smooth", "cyber helmet"), animated lenses, background effects, and Vtuber-style avatars. It takes your webcam feed, applies the effect in real time, and renders the result into OBS Studio through a browser source.

Two things matter for automation:

Streamfog has no public API, CLI, or plugin SDK. You cannot script it directly, and it cannot tell you which lens is active. It is effectively a black box that only listens to Streamer.bot.
Streamer.bot is the remote control. Streamer.bot is a free automation tool for streamers. Streamfog registers itself with Streamer.bot as an integration, and Streamer.bot exposes a local WebSocket server that accepts DoAction commands by name (e.g. fire the action SetLens_BeautySmooth).

This project is the bridge between the two: it gives an AI assistant (or the dashboard, or any script) a clean tool interface — streamfog_set_lens, streamfog_clear_effects, streamfog_toggle_avatar, streamfog_status, streamfog_list_lenses — and translates each call into a Streamer.bot DoAction dispatch. Without this server you would have to open Streamer.bot and click actions manually; with it, your agent becomes a stream producer.

⚠️ Fire-and-forget: Streamer.bot does not report whether an action succeeded, and Streamfog cannot be queried. A tool returning "success" means dispatched, not applied — confirm visually on the stream.


You might use this if…	You want your AI to switch AR lenses, toggle Vtuber avatars, or clear effects during live OBS broadcasts — controlled by Twitch chat events, channel points, or agentic automation.
What it connects to	Streamfog desktop app → Streamer.bot WebSocket → this MCP server
Ports	Backend 10994, Dashboard 10995
Start	`just bootstrap` then `start.ps1`

Related MCP server: obs-showrunner-mcp

How to use this server (3 steps)

Install the two external apps (one-time): Streamfog + Streamer.bot, enable Streamfog's integration inside Streamer.bot, and enable Streamer.bot's WebSocket server on port 8080. Full walkthrough: docs/ONBOARDING.md.
Map your lenses: create lenses.json linking human-readable lens names to the exact Streamer.bot action names that apply them (see Lens Map).
Start and drive it: start.ps1 boots the backend + dashboard; then either connect your MCP client (Claude Desktop / Cursor / opencode) over stdio or http://127.0.0.1:10994/mcp, click lenses on the dashboard, or call the REST API from scripts. All three surface the same bridge.

Architecture

Plain English: your AI talks to this server, this server talks to Streamer.bot, Streamer.bot tells Streamfog what to render, and OBS shows the result. Every hop is local.

┌─────────────┐     MCP            ┌──────────────────┐     WebSocket      ┌──────────────┐
│  LLM Agent  │ ───────────────→  │  streamfog-mcp   │ ────────────────→ │ Streamer.bot  │
│  (Claude,   │ ←───────────────  │  :10994 (FastMCP) │ ←──────────────── │ :8080         │
│   Gemini)   │   stdio / /mcp    │  :10995 (React)   │   DoAction JSON   │               │
└─────────────┘                  └──────────────────┘                    └──────┬────────┘
                                                                                │ Native Hook
                                                                         ┌──────▼────────┐
                                                                         │  Streamfog    │
                                                                         │  Desktop App  │
                                                                         └──────┬────────┘
                                                                                │ Browser Source
                                                                         ┌──────▼────────┐
                                                                         │  OBS Studio   │
                                                                         └───────────────┘

MCP tools (for AI agents): served over stdio or the streamable HTTP endpoint at http://127.0.0.1:10994/mcp.
REST API (for scripts + dashboard): /api/* on the same port, backed by the same bridge instance.
Dashboard (for humans): React SPA at :10995 — lens grid, status KPIs, chat, logs.

The MCP endpoint is served at http://127.0.0.1:10994/mcp (streamable HTTP) in dual mode, alongside the REST API and dashboard.

Quick Start

uv sync
# Edit lenses.json with your Streamer.bot action names
# Set STREAMFOG_MCP_STREAMERBOT_TOKEN in .env if using auth
.\start.ps1

MCP-only via stdio (for Cursor, Claude Desktop):

uv run -m streamfog_mcp --stdio

Prerequisites

Streamfog installed and running
Streamer.bot installed and running
Streamfog → Streamer.bot integration enabled in Streamfog's Integrations panel
Streamer.bot WebSocket server enabled (Settings → WebSocket Server)
Actions created in Streamer.bot (e.g. SetLens_BeautySmooth, ClearEffects, ToggleAvatar)
lenses.json populated with your action→lens mappings

See docs/ONBOARDING.md for the step-by-step walkthrough.

Configuration

Variable	Default	Description
`STREAMFOG_MCP_STREAMERBOT_HOST`	`127.0.0.1`	Streamer.bot WebSocket host
`STREAMFOG_MCP_STREAMERBOT_PORT`	`8080`	Streamer.bot WebSocket port
`STREAMFOG_MCP_STREAMERBOT_TOKEN`	—	Streamer.bot auth token
`STREAMFOG_MCP_LENS_MAP_PATH`	`lenses.json`	Path to lens→action mapping file
`STREAMFOG_MCP_PORT`	`10994`	Backend port
`STREAMFOG_MCP_LOG_LEVEL`	`INFO`	Logging level

Lens Map (`lenses.json`)

{
  "beauty_smooth": "SetLens_BeautySmooth",
  "cyber_helmet": "SetLens_CyberHelmet",
  "vtuber_avatar": "SetLens_VTuberAvatar"
}

Keys are human-readable lens identifiers used in MCP tool calls. Values are the corresponding Streamer.bot action names. Keys starting with _ are ignored; unknown identifiers fall back to the action SetLens_{identifier}.

MCP Tools (5)

Lens Control

Tool	Description
`streamfog_set_lens`	Activate a specific AR lens or face filter
`streamfog_clear_effects`	Strip all effects, return camera to baseline
`streamfog_toggle_avatar`	Toggle Vtuber-style avatar on/off

Discovery — READ_ONLY

Tool	Description
`streamfog_list_lenses`	List all configured lenses from lenses.json
`streamfog_status`	Bridge connection health + lens count

REST API

Endpoint	Method	Description
`/api/health`	GET	Liveness probe (status, version, uptime, tool count, bridge)
`/api/v1/status`	GET	Server + bridge health
`/api/v1/lenses`	GET	List all lenses
`/api/v1/lenses/set`	POST	Activate a lens (`{"lens_identifier": "beauty_smooth"}`)
`/api/v1/lenses/reload`	POST	Reload lens map from disk
`/api/v1/effects/clear`	POST	Clear all effects
`/api/v1/avatar/toggle`	POST	Toggle avatar
`/api/tools`	GET	Dynamic MCP tool list with schemas
`/api/capabilities`	GET	Capability discovery
`/api/skills`	GET	Skill list
`/api/skills/{name}`	GET	Skill content (markdown)
`/api/llm/discover`	GET	Local LLM provider probe (Ollama/LM Studio/vLLM) + GPU
`/api/logs`	GET	Ring-buffer log window
`/api/v1/diagnostics`	GET	Tool list, system info, errors

Web Dashboard

Dark SOTA dashboard at :10995 (React + Vite + Tailwind + Zustand):

Dashboard — hero + KPI cards (server, tools, bridge, uptime), lens grid, quick actions, exponential-backoff health
Tools — dynamic tool list with schemas from /api/tools
Chat — skill-first local LLM chat (Ollama/LM Studio/vLLM), 4 personalities, localStorage history, export
Settings — backend health + LLM provider detection
Help — architecture, env reference, troubleshooting
Logs — live ring-buffer modal (Ctrl+L)

Keyboard: Ctrl+Scroll zoom, Ctrl+0 reset, Ctrl+L logs.

Project Structure

streamfog-mcp/
├── src/streamfog_mcp/
│   ├── _mcp.py              FastMCP singleton + resources
│   ├── server.py            FastAPI gateway (REST + /mcp mount)
│   ├── __main__.py          CLI entry (--stdio / --serve)
│   ├── config.py            Pydantic settings (STREAMFOG_MCP_ prefix)
│   ├── errors.py            _error_response() with logger.exception
│   ├── logging_ring.py      Ring buffer for /api/logs
│   ├── skills/streamfog/    SKILL.md (chat preprompt)
│   ├── tools/core_tools.py  5 @mcp.tool() decorators
│   └── services/streamerbot.py  Streamer.bot WebSocket client
├── webapp/                  Vite + React 19 + Tailwind + Zustand
├── native/                  Tauri 2.0 desktop wrapper
├── lenses.json              Lens → action mapping
├── pyproject.toml / uv.lock
├── start.ps1 / start.bat
├── justfile
└── tests/                   13 tests (units + endpoint + e2e)

Verification

just lint          # ruff
just test          # pytest (coverage-gated)
uv run pyright src/  # types
cd webapp && bun run check && bun run biome:ci
cd webapp && bunx playwright test   # e2e

Known Limitations

Streamfog does not expose a native CLI or local API — all control goes through Streamer.bot
Lens activation is fire-and-forget (Streamer.bot does not report success/failure for actions)
No lens preview or thumbnail retrieval (Streamfog desktop is a black box)
Lumia/Crowd Control bridge path is documented but not yet implemented as an alternative transport

Available Tools

5 tools

streamfog_clear_effectsA

Strip all active AR assets, face filters, and canvas overlays in Streamfog.

Returns the camera feed to a clean, unfiltered video baseline. Dispatches the 'ClearEffects' action to Streamer.bot.

Return Format

{"success": true, "message": "All effects cleared — camera returned to baseline", "data": {"action": "ClearEffects"}}

Examples

await streamfog_clear_effects()

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses that the tool dispatches the 'ClearEffects' action to Streamer.bot and returns the camera to baseline. It also includes the return format. Annotations only provide readOnlyHint=false, and the description adds meaningful behavioral context beyond that.

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 concise with three sentences covering purpose, action dispatch, return format, and an example. Every sentence is valuable and front-loaded.

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 zero-parameter tool with an output schema, the description fully covers behavior, action, return format, and provides an example. No additional context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so the description does not need to add parameter meaning. The schema coverage is 100% (empty), and the baseline for zero parameters is 4.

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's function: 'Strip all active AR assets, face filters, and canvas overlays' and 'Returns the camera feed to a clean, unfiltered video baseline.' This is specific and distinct from sibling tools like streamfog_set_lens or streamfog_toggle_avatar.

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 usage when effects need to be cleared, but it does not provide explicit guidance on when to use versus alternatives, nor does it mention prerequisites or exclusion conditions.

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

streamfog_list_lensesA

Read-only

List all available AR lenses and face filters from the local lenses.json mapping.

Returns all lens identifiers and their corresponding Streamer.bot action names. Use reload=true to force a re-read from disk if lenses.json was modified.

Return Format

{"success": true, "data": {"lenses": {"beauty_smooth": "SetLens_BeautySmooth", "cyber_helmet": "SetLens_CyberHelmet"}, "count": 2, "path": "lenses.json"}}

Examples

await streamfog_list_lenses() await streamfog_list_lenses(reload=True)

ParametersJSON Schema

Name	Required	Description	Default
`reload`	No	If true, reload the lens map from disk before listing.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

The description adds behavioral details beyond readOnlyHint: the default cache behavior and the effect of reload=true. It also includes return format and examples, disclosing side 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?

The description is efficient, using concise sentences and clear sections (Return Format, Examples). Every sentence adds value without redundancy.

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 list tool with one optional parameter, the description fully covers purpose, behavior, parameters, and return format. Examples further aid understanding.

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%, so baseline is 3. The description adds context on when to use reload, but does not significantly extend the schema's description. Adequate.

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 lists all available AR lenses and face filters from a local file, with specific verb and resource. It distinguishes from siblings like streamfog_set_lens by being read-only.

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?

It explains when to use the reload parameter but does not explicitly contrast with other sibling tools. The context from sibling names makes the usage clear, but direct guidance is lacking.

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

streamfog_set_lensA

Activate a specific AR lens or face filter in Streamfog.

Resolves the lens identifier against the local lenses.json mapping file and dispatches the corresponding action to Streamer.bot. Falls back to a constructed action name 'SetLens_{identifier}' if no mapping found.

Return Format

{"success": true, "message": "Action 'SetLens_CyberHelmet' dispatched", "data": {"action": "SetLens_CyberHelmet", "lens": "cyber_helmet"}}

Examples

await streamfog_set_lens("beauty_smooth") await streamfog_set_lens("cyber_helmet")

ParametersJSON Schema

Name	Required	Description	Default
`lens_identifier`	Yes	The lens identifier to activate (e.g. 'cyber_helmet', 'beauty_smooth', 'vtuber'). Must match a key in lenses.json or an action name configured in Streamer.bot.

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.4/5.0

Behavior4/5

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

The description reveals important behaviors: it resolves the lens identifier against a mapping file, falls back to a constructed action name, and dispatches an action. It also includes the return format. Annotations only provide readOnlyHint=false, so the description adds substantial context. However, it does not disclose authorization requirements or error handling.

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 concise, well-structured with sections for return format and examples. Each sentence adds value without redundancy. It is front-loaded with the core purpose.

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?

Given the tool's low complexity (one parameter, no nested objects) and the presence of an output schema, the description provides complete context: purpose, parameter behavior, fallback logic, return format, and examples. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole parameter 'lens_identifier' is fully described in the schema (100% coverage), and the description adds meaningful details: how the identifier is resolved (against lenses.json), fallback behavior, and examples of valid values. This significantly aids correct invocation.

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 activates a specific AR lens or face filter. It uses a specific verb ('Activate') and resource ('AR lens or face filter'), and distinguishes from sibling tools like streamfog_clear_effects and streamfog_list_lenses.

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 usage by describing the activation process, but it does not explicitly state when to use this tool versus alternatives like streamfog_clear_effects or streamfog_list_lenses. No when-not or sibling comparisons are provided.

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

streamfog_statusA

Read-only

Check the connection status to Streamfog via the Streamer.bot bridge.

Returns bridge connectivity, loaded lens count, and any recent errors. Use this before attempting lens operations to verify the bridge is healthy.

Return Format

{"success": true, "data": {"connected": bool, "host": "127.0.0.1", "port": 8080, "lenses_loaded": 5, "connected_at": 1715000000.0, "last_error": null}}

Examples

await streamfog_status()

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark readOnlyHint true, and description adds detailed behavioral context: returns bridge connectivity, lens count, and errors. No contradictions.

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?

Concise, well-structured description with 4 sentences, return format, and example. No wasted words.

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?

Comprehensive given zero parameters, annotations present, and output schema provided via return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, so baseline 4. Description does not need to add parameter info.

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 it checks connection status to Streamfog via bridge, lists returned data (connectivity, lens count, errors), and distinguishes from sibling tools that perform lens operations.

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 advises using this tool before lens operations to verify bridge health, providing clear usage context. Does not mention alternatives, but siblings are sufficiently different.

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

streamfog_toggle_avatarA

Toggle the Vtuber-style avatar overlay on or off in Streamfog.

Dispatches the 'ToggleAvatar' action to Streamer.bot. If no avatar is currently active, this activates the default avatar lens. If an avatar is active, it deactivates it.

Return Format

{"success": true, "message": "Avatar toggled", "data": {"action": "ToggleAvatar"}}

Examples

await streamfog_toggle_avatar()

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Annotations only provide readOnlyHint=false, while the description adds valuable context: it dispatches a 'ToggleAvatar' action, activates default lens if none active, and deactivates if active. This goes beyond the annotation without contradicting it.

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 concise, front-loaded with the main purpose, and structured with clear sections including return format and example. Every sentence adds value with no redundancy.

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 parameterless toggle with an output schema, the description covers all necessary information: behavior on toggle, action dispatched, return format, and example. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has no parameters (0 params, 100% coverage), so baseline is 4. The description includes an example with no arguments, consistent with the empty 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 states the verb 'Toggle' and the resource 'Vtuber-style avatar overlay'. It distinguishes this tool from its siblings (e.g., streamfog_status, streamfog_set_lens) by specifying the toggle action and default behavior.

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 explains when to use it (to toggle avatar on/off) and provides context with sibling tool names, but does not explicitly state when not to use it or name alternatives.

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. Dates show when Glama detected each change.

5 tool updatesv0.1.0Jul 30, 2026
- First observedstreamfog_clear_effects
- First observedstreamfog_list_lenses
- First observedstreamfog_set_lens
- First observedstreamfog_status
- First observedstreamfog_toggle_avatar

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: status checks connectivity, set_lens activates a specific lens, clear_effects removes all effects, toggle_avatar toggles the avatar overlay, and list_lenses enumerates available lenses. There is no functional overlap.

Naming Consistency5/5

All tool names follow a consistent streamfog_verb_noun pattern using snake_case. Verbs are descriptive and uniform, making it easy to predict tool behavior from the name.

Tool Count5/5

Five tools is well-scoped for an AR lens management server. Each tool serves a core function: status, set lens, clear effects, toggle avatar, and list lenses, without unnecessary duplication.

Completeness4/5

The tool set covers essential operations for managing AR lenses, including status checking, activation, clearing, avatar toggling, and listing. A minor gap is the lack of a tool to get the currently active lens or avatar state, though status provides bridge health.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

sleipnirOAuth
tv.sleipnir
Multistream to Twitch, YouTube and Kick; generate OBS overlays from a plain-English prompt.
Social Media Image & Video Processing
1
StoryStudioOAuth
io.github.HelloElo-Fr
AI image, video, voice and music generation over MCP, routed to Veo 3.1, Seedance 2.0 and more.
AI & Machine Learning Image & Video Processing Audio Processing
1
ViewMax MCP A
io.github.bytevirts
Remote MCP for AI video, image, music and speech generation.
Audio Processing Image & Video Processing Speech Processing
141
AI.TV MCP ServerOAuth
tv.ai
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
Entertainment & Media AI & Machine Learning
2

Related MCP Servers

OBS MCP
Entertainment & Media Multimedia Processing
xDarkzx
A
license
B
quality
A
maintenance
AI-powered stream and recording control for OBS Studio through the Model Context Protocol
Updated a month ago (2026-08-02 02:54 UTC)
100
4
Apache 2.0
obs-showrunner-mcp
Entertainment & Media Multimedia Processing
takurot
A
license
B
quality
C
maintenance
MCP server enabling LLMs to control OBS Studio through high-level show and effect APIs.
Updated 8 months ago (2026-01-05 07:09 UTC)
18
15
MIT
obs-studio-mcp
Entertainment & Media Multimedia Processing
aaronckj
A
license
B
quality
B
maintenance
MCP server for controlling OBS Studio via obs-websocket, enabling scene switching, source management, streaming, recording, and text overlays through natural language.
Updated a month ago (2026-07-28 20:48 UTC)
36
1
MIT
streamlabs-mcp
Entertainment & Media
AhmadTariq1337
A
license
B
quality
B
maintenance
MCP server that gives AI assistants direct control over Streamlabs Desktop, enabling scene switching, source/audio management, and streaming/recording controls through natural language.
Updated 24 days ago (2026-08-13 11:31 UTC)
59
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandraschi/streamfog-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Streamfog MCP

What is Streamfog?

How to use this server (3 steps)

Architecture

Quick Start

Prerequisites

Configuration

Lens Map (lenses.json)

MCP Tools (5)

Lens Control

Discovery — READ_ONLY

REST API

Web Dashboard

Project Structure

Verification

Known Limitations

Available Tools

Return Format

Examples

Output Schema

Return Format

Examples

Output Schema

Return Format

Examples

Output Schema

Return Format

Examples

Output Schema

Return Format

Examples

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Lens Map (`lenses.json`)