Obsbot MCP vs Server Everything
A side-by-side look at the Obsbot MCP and Server Everything MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose Obsbot MCP for embedded system work as a local process; choose Server Everything for other tools and integrations as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
Choose Obsbot MCP when
- You need dedicated capabilities in the Embedded System domain.
- You prefer a local stdio subprocess transport.
- You want tools like
obsbot_devices, obsbot_wake, obsbot_sleep.
Choose Server Everything when
- You need dedicated capabilities in the Other Tools and Integrations domain.
- You prefer a local stdio subprocess transport.
- Its auth model fits you: No auth required.
Feature & specification comparison
Rows where the two servers differ are marked.
| Spec | ||
|---|---|---|
| Category | Embedded System | Other Tools and Integrations |
| Quality signal | 64/100 · Good | 55/100 · Good |
| Install command | Confirmed | Confirmed |
| Transport | Local subprocess (stdio) | Local subprocess (stdio) |
| Auth | Not declared | No auth required |
| Pricing | Not declared | Free |
| Required env vars | None listed | None listed |
| Verified owner | Community listing | Community listing |
| GitHub stars | 2 | 91,405 |
| Directory activity | 2 views 0 installs 0 upvotes | 9 views 0 installs 0 upvotes |
| Tools | 80 | Not listed |
| Full listing | View Obsbot MCP | View Server Everything |
Tools & capabilities
Obsbot MCP tools 80
obsbot_devicesList attached OBSBOT-compatible cameras. Each entry is { serial?, locationId?, name, status, reason? }: serial is the value to pass as `camera` to any camera-addressing tool (present where obtainable — reading it requires briefly opening the camera); status is available (free to bind), bound (already opened by this process), or busy (could not be opened and identified, so it can't be targeted here — usually another process holds it, but it also covers a camera that opened yet would not answer). On a busy entry, `reason` carries the underlying error and distinguishes those cases.obsbot_wakeWake the camera/gimbal (sends "run"). This MOVES the camera: waking un-stows the gimbal and brings it back to level (pitch ~0). Most control commands also wake the camera implicitly as a side effect.obsbot_sleepSleep the camera/gimbal (sends "sleep"). This MOVES the camera: sleeping STOWS the gimbal, tilting it face-down to roughly pitch 84°, so obsbot_gimbal_position will read ~84 rather than the pose you left it in. obsbot_wake un-stows it.obsbot_gimbal_moveMove the gimbal to an absolute yaw/pitch angle (degrees); positive yaw pans to the camera's left, positive pitch tilts down. Yaw is clamped to [-130,130], pitch to [-90,90]. Absolute positioning (1:1 degrees), verified on hardware.obsbot_gimbal_recenterRecenter the gimbal — drives it back to yaw 0 / pitch 0 (level and facing forward). Returns as soon as the command is sent: the gimbal may still be moving, so poll obsbot_gimbal_position if you need to know it has arrived.obsbot_zoom_uvcStandard UVC zoom: set an absolute zoom ratio, clamped to [1.0, 2.0]. Snaps to the requested target exactly (unlike obsbot_zoom_vendor, whose ratio scale differs and may not land exactly where asked). Waits for the zoom to actually arrive and returns { settled }: the ramp is not instant (a full 1.0->2.0 sweep takes about 2.4s), and obsbot_aim_at_pixel and obsbot_zoom_to_fit both refuse while it is in flight, so this returning early would just move the failure downstream. settled:false means the zoom had not arrived within the timeout — the command was still sent.obsbot_ai_trackEnable or disable AI tracking and choose the mode. When enabled the camera follows the subject; disabling stops tracking. `mode` is either a human framing (normal | upper-body | close-up | headless | lower-body) or a standalone scene mode (group | whiteboard | desk | hand); scene modes imply enabled:true. After writing, the tool polls the status block until the mode settles and returns { verified, matched } — the aiMode the device actually landed on (matched:false means no subject was being tracked, so the mode could not take effect yet).obsbot_ai_track_speedSet the AI tracking-speed preset (OBSBOT Center's Standard/Sport). speed: standard (slower follow) | sport (snappier follow).obsbot_zoom_vendorVendor zoom path with adjustable speed: zoom to a ratio at a chosen speed. This tool's ratio scale differs from obsbot_zoom_uvc's and may not land exactly on the requested target. ratio is clamped to [1.0,2.0]; speed 0=device default, 1-10 slow→fast, 255=maximum.obsbot_focus_faceEnable or disable face-priority autofocus.obsbot_statusRead the camera's live status block. Returns { awake, hdr, faceAe, aiMode, trackSpeed, fovMode, zoomPercent, focusMode, focusPosition }: faceAe is whether auto-exposure is metering for a detected face; aiMode is the current AI framing (no-tracking|normal|upper-body|close-up|headless|lower-body|desk|whiteboard|hand|group|unknown); trackSpeed is standard|sport|unknown; fovMode is the field-of-view mode (wide|medium|narrow|custom|unknown), where custom means a continuous zoom overrode the discrete modes; zoomPercent is the zoom position, 0-100; focusMode is auto|manual|unknown. focusPosition is present ONLY in manual mode, on the same 0-100 scale obsbot_focus_manual takes: under autofocus this camera does not expose the motor, it echoes the last written value, so reporting it would look like a live focus distance while being stale. Focus is a standard UVC control rather than a field of the status block, so it costs an extra read; a device that cannot answer it reports focusMode unknown rather than failing the whole read. Under --debug the result also carries `raw`: the full 60-byte status block as hex (for reverse-engineering undecoded offsets).obsbot_image_fovSet the field of view. fov: wide (86°) | medium (78°) | narrow (65°).- +68 more on the listing page
Server Everything tools
No tool names declared yet. Check the project README from the listing page.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
Obsbot MCP
{
"mcpServers": {
"lxman-obsbot-mcp": {
"command": "npx",
"args": [
"-y",
"obsbot-mcp"
]
}
}
}
Server Everything
{
"mcpServers": {
"modelcontextprotocol-server-everything": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-everything"
]
}
}
}
Frequently asked questions
Obsbot MCP is categorized under Embedded System and uses a local stdio subprocess. Server Everything belongs to Other Tools and Integrations and uses a local stdio subprocess. Pick Obsbot MCP for embedded system work and Server Everything for other tools and integrations.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client.
Obsbot MCP has no declared pricing — check the project's own site. Server Everything is listed as free. Auth: no auth required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add lxman-obsbot-mcp and modelcontextprotocol-server-everything as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, Obsbot MCP has a quality signal of 64/100 (Good) with 2 views, 0 installs and 2 GitHub stars. Server Everything has 55/100 (Good) with 9 views, 0 installs and 91,405 GitHub stars.