Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MAX_DATANoMax data size per variable2048
LOG_LEVELNoLog level: debug, info, warn, errorinfo
MAX_DEPTHNoMax depth for variable inspection3
XDEBUG_HOSTNoHost to bind0.0.0.0
XDEBUG_PORTNoPort to listen for Xdebug connections9003
MAX_CHILDRENNoMax children to return for arrays/objects128
PATH_MAPPINGSNoJSON object mapping container to host paths
COMMAND_TIMEOUTNoCommand timeout in milliseconds30000

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": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_sessionsA

List all active PHP debug sessions with their current state

get_session_stateC

Get detailed state of a specific debug session including current position and status

set_active_sessionA

Set which debug session should be the active/default session for subsequent commands

close_sessionC

Close and terminate a debug session

set_breakpointA

Set a breakpoint in PHP code. Supports line breakpoints and conditional breakpoints with hit counts. Can be set before a debug session starts - breakpoints will be applied when a session connects.

set_exception_breakpointA

Set a breakpoint that triggers when a specific exception is thrown. Can be set before a debug session starts.

set_call_breakpointB

Set a breakpoint that triggers when a specific function is called. Can be set before a debug session starts.

remove_breakpointA

Remove a breakpoint by its ID. Works for both active session breakpoints and pending breakpoints.

update_breakpointB

Update a breakpoint (enable/disable or change hit conditions). Works for both active session and pending breakpoints.

list_breakpointsB

List all breakpoints including both active session breakpoints and pending breakpoints

continueB

Continue script execution until the next breakpoint or end of script

step_intoA

Step into the next function call, or to the next line if not a function call. This follows execution into called functions.

step_overA

Step over to the next line in the current scope. Function calls are executed but not stepped into.

step_outA

Step out of the current function. Execution continues until the current function returns.

stopA

Stop the debug session and terminate script execution immediately

detachB

Detach from the debug session and let the script continue running without debugging

get_stack_traceC

Get the current call stack showing all function calls leading to the current position

get_contextsB

Get available variable contexts (Local, Superglobals, User-defined constants) at the current position

get_variablesA

List all variables in scope with metadata (names, types, child counts). Use get_variable() to inspect specific variable values. Returns lightweight metadata for browsing the variable tree.

get_variableC

Get a specific variable by name, including nested properties. Use PHP syntax for nested access (e.g., '$user->name', '$array[0]', '$obj->items[2]->value')

set_variableC

Set the value of a variable in the current scope

evaluateA

Evaluate a PHP expression in the current context. Returns the result of the expression. Use for calculations, method calls, or inspecting computed values.

get_sourceC

Get the source code of a file or a specific line range

add_watchA

Add a watch expression that will be evaluated on each break. Watch expressions persist across steps.

remove_watchC

Remove a watch expression

evaluate_watchesC

Evaluate all watch expressions and return their current values

list_watchesB

List all active watch expressions

add_logpointC

Add a logpoint that logs messages without stopping execution. Use {varName} placeholders for variables.

remove_logpointC

Remove a logpoint

get_logpoint_historyC

Get the log output history from logpoints

start_profilingB

Start profiling to track memory usage and execution time

stop_profilingC

Stop profiling and get the results

get_profile_statsC

Get current profiling statistics

get_memory_timelineB

Get memory usage timeline from profiling

capture_request_contextC

Capture the current HTTP request context ($_GET, $_POST, $_SESSION, $_COOKIE, headers)

add_step_filterB

Add a step filter to skip certain files/directories during stepping (e.g., vendor code)

list_step_filtersB

List all step filter rules

get_function_historyC

Get the history of function calls made during debugging

start_coverageB

Start tracking code coverage during debugging

stop_coverageB

Stop tracking code coverage and get the report

get_coverage_reportB

Get the current code coverage report

save_debug_profileA

Save the current debug configuration (breakpoints, watches, filters) as a named profile

load_debug_profileC

Load a saved debug profile

list_debug_profilesB

List all saved debug profiles

export_sessionC

Export the current debug session as a report

capture_snapshotC

Capture a snapshot of the current debug state for the export report

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

B3.1/5.0

Scored across 46 tools

Disambiguation4/5

Most tools have clearly distinct purposes, but there is some overlap in the variable inspection/evaluation trio (get_variables, get_variable, evaluate) and session termination trio (stop, detach, close_session) where users may need to read carefully to pick the right one. Overall, however, the tool names and descriptions are specific enough to disambiguate.

Naming Consistency4/5

The majority of tools follow a consistent verb_noun snake_case pattern (e.g., set_breakpoint, get_variable, add_watch). A few exceptions like continue, detach, evaluate, and stop break the pattern, and there is mild inconsistency between profile vs profiling terminology (start_profiling vs get_profile_stats). These are minor deviations rather than chaotic naming.

Tool Count2/5

At 46 tools, the surface is very large and exceeds the point where users can easily hold the toolset in mind. While Xdebug is a feature-rich debugger with many legitimate operations, many of these tools (e.g., separate snapshot/export/profile tools) could be consolidated or exposed as optional sub-commands.

Completeness4/5

The tool set covers the main debugging workflow well: sessions, breakpoints, stepping, variables, watches, logpoints, source, profiling, and coverage. There are a few gaps such as no remove_step_filter or delete_debug_profile, but these are edge operations rather than core workflow blockers.

Maintenance

ActivityMaintained
ResponsivenessNo issues