bc-rig
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| browser_sessionA | Start, select, inspect, list, or stop isolated project browsers. Start requires an AL launch.json path. |
| doctorB | Check host, Android, Playwright, and project browser-session readiness. |
| browser_observeA | Read the selected project browser. Call browser_session first. Compact returns stable @b refs; full is costly. |
| browser_actB | Act in the selected project browser. Use an @b ref from browser_observe; returns changed state. |
| browser_screenshotA | Save a BC screenshot and return its path. Use only when visual evidence matters. |
| mobile_observeB | Read compact MobileNAV state with stable @m refs; full adds classes and bounds. |
| mobile_actA | Operate MobileNAV. Use @m refs for tap/type/wait. Returns compact state, avoiding a separate observe call. |
| mobile_screenshotA | Save a MobileNAV screenshot and return its path. Use only for visual evidence. |
| runC | Start, inspect, annotate, or finish the evidence manifest for an exploratory run. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a clear, distinct purpose within its category (browser vs mobile vs utility). Browser tools cover session management, observation, action, and screenshot; mobile tools cover observation, action, and screenshot; doctor and run are unique utilities. No two tools appear to do the same thing.
Most tools follow a consistent [category]_[action] pattern (browser_*, mobile_*), which is clear and predictable. The doctor and run tools deviate slightly as they lack a category prefix, but they are still verb-named and not ambiguous. Overall, naming is mostly consistent with minor deviations.
With 9 tools, the server is well-scoped for its purpose: browser automation, mobile automation, and basic utilities. Each tool earns its place, and the number is neither too few nor too many for the apparent breadth of functionality.
The tool surface covers core browser and mobile interactions (observe, act, screenshot) and includes a readiness check (doctor) and manifest management (run). However, mobile session management is absent (no mobile_session tool), while browser has browser_session. This is a notable gap that could hinder mobile workflows.