Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
SHINYPROBE_HEADEDNoSet to '1' to run the browser in headed mode (watch the browser).
SHINYPROBE_PYTHONNoPath to the python executable to use for Python apps. If not set, uses python on PATH.
SHINYPROBE_RSCRIPTNoPath to the Rscript executable to use for R apps. If not set, uses Rscript found on PATH or default install folder on Windows.

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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
launch_appA

Start the Shiny app at path and open it in a browser, then wait for the first load to settle.

path is a folder with app.R, ui.R + server.R, or app.py, or the app.R / app.py file itself. interpreter overrides the Rscript or Python executable. Launching the same path again stops the old copy and relaunches it under the same app_id (use this after a crash or a code change). With replay=True, the set_inputs, click, upload_file and show actions from the previous run of this path are run again in order, to get back to the same state; replay says how many ran and which one failed, if any, and the envelope covers the load and every replayed action.

attachB

Open an app that is already running (local or deployed) at url and wait for it to settle.

stop_appB

Close the browser page and, for launched apps, stop the app process.

list_controlsA

List every input (id, type, label, current value, choices, visible) and output (id, type, status, visible). Call again after dynamic UI changes: the page is re-scanned every time.

set_inputsA

Set one or more inputs, e.g. {"n": 5, "species": ["setosa"]}, through their widgets, then wait for the app to settle. Warns if an input ends up with a different value than asked for. Use click for buttons and upload_file for file inputs.

clickA

Click the element with this id (usually an action button), then wait for the app to settle. If it is on another tab or in a closed panel, those are opened first, as a user would.

showA

Bring an element into view: target is an element id, or a tab, accordion panel or

upload_fileB

Upload the local file at path into the file input id, then wait for the app to settle.

read_outputsA

Read outputs (all of them when ids is empty). Text and HTML come back as text, tables as columns plus data rows (first 50, with the total), plots, images and htmlwidgets as images after the JSON summary. Plots also give each panel's axis ranges (and the mapped variables for ggplot2) in data; htmlwidgets give the data payload they were sent.

get_errorsA

Every error seen so far: server errors with traces (and the output they broke), Shiny output errors, browser console errors, and the app exiting. With since_last=True, only errors since the previous since_last call.

get_consoleA

The app's console output (print, message, cat, logging), newest last: the last lines lines, or with since_last=True everything since the previous since_last call. Long output keeps the newest lines and says how many older ones were cut. Only for apps started with launch_app.

screenshotA

Take a PNG screenshot of the whole page, or of one element when id is given.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 12 tools

Disambiguation5/5

Every tool targets a distinct action: lifecycle (attach, launch_app, stop_app), UI inspection (list_controls), interaction (set_inputs, click, show, upload_file), output reading (read_outputs), and diagnostics (get_errors, screenshot, get_console). No two tools overlap in purpose, making misselection highly unlikely.

Naming Consistency5/5

All names follow a consistent verb_noun pattern in snake_case (e.g., launch_app, set_inputs, read_outputs). Single verbs like attach and click are still clear and fit the pattern, with no mixed conventions or vague terms.

Tool Count5/5

12 tools is well-scoped for a Shiny app interaction server. Each tool covers a necessary capability for starting, controlling, inspecting, and debugging apps, without redundancy or bloat.

Completeness5/5

The surface covers the full lifecycle from launch to stop, all common input interactions, output reading, and error/console diagnostics. No obvious gaps exist for typical Shiny testing workflows, making the set self-sufficient.

Maintenance

ActivityMaintained
ResponsivenessNo issues