Skip to main content
Glama
debugmcp

MCP Debugger

by debugmcp
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

get_local_variables

Retrieve local variables for the current debug stop to inspect runtime values. Pass exact names to fetch specific bindings and avoid mislabeling global scope.

Instructions

Get local variables for the shared inspection anchor. If the stopped thread is frameless, a sibling with policy-recognized user frames is preferred, adopted, and disclosed in note. At a breakpoint or step inside a frame the stack display hides as internal (a node_modules dependency), the anchor is that frame — the one the program stopped in — and note says so. A JavaScript frame with no Local/block scope returns empty with guidance instead of mislabeling Global bindings. Responses are size-guarded; pass names:[...] to fetch specific variables in full

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
namesNoOnly return variables with these exact names (case-sensitive). Requested names missing from the scope are listed in the response's notFound.
sessionIdYes
includeSpecialNoInclude special/internal variables like this, __proto__, __builtins__, etc. Default: false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.25.1
    • addedInput schema / properties / names
      Added value: +{
+  "description": "Only return variables with these exact names (case-sensitive). Requested names missing from the scope are listed in the response's notFound.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observed

TDQS

A3.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does substantively: it discloses frameless-thread handling, sibling preference/adoption with disclosure in a note, anchor semantics at breakpoints, and the empty-with-guidance fallback for JS frames. It omits error cases, permissions, and pagination specifics, but the edge-case disclosure is above average.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose in the first sentence, which is good, but the following sentences are long and built on undefined jargon ('shared inspection anchor', 'note'), which reduces readability. Every sentence is doing work, but the density hurts comprehension.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should explain the response shape and key concepts, yet 'anchor' and 'note' are never defined and the return structure is only partially implied. It covers edge cases adequately but leaves the agent guessing on core semantics.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 67%, with names and includeSpecial already documented in the schema. The description adds one genuine insight beyond the schema — that names:[...] is the workaround for size-guarded responses — but does not clarify sessionId or the broader fetch semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (get local variables) and adds a distinguishing scope concept ('shared inspection anchor') that separates it from the sibling get_variables/get_scopes. However, it never names or contrasts those siblings explicitly, so differentiation is implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives behavioral context for specific situations (frameless thread, pause inside an internal frame, JS frame with no Local scope), which is useful guidance. But it never says when to call this tool versus get_variables or get_scopes, so routing to alternatives is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools