Skip to main content
Glama

list_scripts

Read-only

Discovers JavaScript loaded in the selected debugger context, including external, inline, and eval scripts, so you can find scripts and context-scoped IDs before fetching sources.

Instructions

Discovers JavaScript currently loaded in the selected debugger context—the main frame by default, or the frame chosen with select_frame. Use select_frame first for iframe-specific source/debugger work. Includes external, inline, and eval scripts in that context; if you already know a function name, endpoint, or code literal, use search_in_sources instead. Each result includes a context-scoped scriptId that expires on reload, navigation, or debugger target change and, for external scripts, a URL that is the preferred selector for get_script_source or save_script_source.

Input Schema

NameRequiredDescriptionDefault
filterNoCase-insensitive URL substring used to narrow external scripts. It does not search source text or match unnamed inline/eval scripts; use search_in_sources for code-content queries.
pageIdxNoPage number (0-based). Defaults to 0.
pageSizeNoMaximum items per page. Defaults to 20.

Output Schema

NameRequiredDescriptionDefault
okYesWhether the tool completed successfully.
dataNo
toolYesStable MCP tool name.
errorNo
summaryYesConcise human-readable outcome.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.0.5

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the read-only safety profile, and the description adds substantially beyond them: context scoping, inclusion of external/inline/eval scripts, and the crucial lifecycle fact that scriptId expires on reload, navigation, or target change. It also recommends URL as the preferred stable selector for downstream calls.

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

Conciseness4/5

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

Front-loaded with the core action, then alternatives, then result semantics. Dense and mostly waste-free, though the final sentence is long and packs several ideas (scriptId lifecycle, URL preference) that could be split for faster scanning.

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

Completeness5/5

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

Output schema exists, yet the description still usefully summarizes what each result contains (context-scoped scriptId, external URL) and warns about expiry. Nothing needed to invoke correctly or to pick the right follow-up tool is missing.

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 description coverage is 100%, so the schema already explains filter as a case-insensitive URL substring and the paging params. The description adds only indirect guidance about external vs inline/eval scripts, leaving the baseline 3 appropriate.

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

Purpose5/5

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

States a specific verb and resource ("Discovers JavaScript currently loaded in the selected debugger context") plus the default scope (main frame) and the exception (frame chosen with select_frame). Clearly separable from siblings like search_in_sources and get_script_source.

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

Usage Guidelines5/5

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

Gives explicit routing rules: call select_frame first for iframe-specific work, and use search_in_sources instead when a function name, endpoint, or code literal is already known. Both the when and the when-not are named with concrete triggers.

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