Skip to main content
Glama
AgentSensor

AgentSensor

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
get_runtime_errorsA

ALWAYS CALL THIS TOOL FIRST whenever the user mentions an error, bug, crash, broken component/page, or asks you to fix/debug anything. Returns active OPEN runtime, bundler (Vite/Next.js/Storybook), TypeScript, and browser errors from the current dev session (or last 24h), grouped by signature with exact file:line locations.

get_error_detailA

Call this immediately after get_runtime_errors to inspect an error_id. Returns the full source-mapped stack trace (user app frames highlighted, node_modules collapsed), preceding log lines, and the command/browser URL that produced it.

check_fixA

ALWAYS call this after applying a code fix for an error_id to verify whether the error recurred in the running dev server or browser. Reports 'still_failing' if seen again, or 'not_seen' (and moves the error from 'open' to 'resolved' in .agentsensor/status.json).

resolve_errorA

Explicitly marks an error_id (or all currently open errors if error_id is omitted) as resolved in .agentsensor/status.json. If the error ever occurs again later, it automatically moves back to open.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4/5.0

Scored across 4 tools

Disambiguation4/5

The four tools map to distinct stages of the debug loop: listing errors, inspecting one, verifying a fix, and manually resolving. check_fix and resolve_error both mutate error state (open->resolved), which creates slight boundary overlap, but their intent differs (automatic verification vs explicit manual closure).

Naming Consistency4/5

All names use snake_case with a verb_noun shape (get_runtime_errors, get_error_detail, resolve_error, check_fix). The verb choices vary a bit (get/check/resolve) but stay readable and predictable. Minor deviation in verb style keeps it from a perfect 5.

Tool Count5/5

Four highly focused tools cover a tight detect-inspect-verify-resolve workflow with no redundancy. Each tool clearly earns its place and the scope is well-matched to the purpose.

Completeness4/5

The surface covers the full lifecycle: discover errors, inspect detail, verify a fix, and mark resolved. Minor gaps exist (no way to list/dismiss already-resolved errors or mute/ignore a known error), but core agent debugging workflows are supported.

Maintenance

ActivityNo data
ResponsivenessSyncing