js-reverse-mcp

by zhangjia2024

Overview Schema Source Related Servers Discussions Admin

search_in_sources

Read-only

Finds known function names, endpoints, tokens, or code patterns in debugger-loaded JavaScript sources, returning line matches and script IDs without executing or pausing the page.

Instructions

Finds a known function name, endpoint, string literal, token, or code pattern in JavaScript loaded by the selected debugger context—the main frame by default, or the frame chosen with select_frame. It searches external, inline/eval, and minified sources in that context without executing or pausing the page, returning 1-based lines plus context-scoped scriptIds; URLs are the preferred selectors for URL-backed matches. Use select_frame first for iframe-specific source work, get_script_source for nearby context, save_script_source for a whole bundle, or set_breakpoint_on_text when runtime values are needed. For a known captured request, prefer get_request_initiator before a broad source search.

Input Schema

Name	Required	Description
`query`	Yes	Source text to locate, or a regular-expression pattern when isRegex=true. Prefer a distinctive function name, endpoint, property, or literal that can also anchor set_breakpoint_on_text.
`isRegex`	No	Interpret query as a regular expression when true. Leave false for literal endpoint, token, and code-text searches.
`urlFilter`	No	Case-insensitive script-URL substring used to narrow matches to a known bundle or domain. It excludes unnamed inline/eval scripts.
`maxResults`	No	Maximum matches to return (default: 30). Narrow with urlFilter before increasing this for common text.
`caseSensitive`	No	Match case exactly when true. Leave false for discovery; set true when choosing exact code text for a breakpoint.
`maxLineLength`	No	Maximum characters in each matched-line preview (default: 150). Use get_script_source rather than a very large preview when surrounding context is needed.
`excludeMinified`	No	Skip sources with very long lines when true. Keep the default false for reverse engineering because relevant code often exists only in compressed bundles.

Output Schema

Name	Required	Description
`ok`	Yes	Whether the tool completed successfully.
`data`	No
`tool`	Yes	Stable MCP tool name.
`error`	No
`summary`	Yes	Concise human-readable outcome.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.0.5Oct 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations declare readOnlyHint and destructiveHint false, but the description adds important behavior beyond that: it searches without executing or pausing the page, covers external, inline/eval, and minified sources, and returns 1-based lines plus context-scoped scriptIds. It also notes that URLs are preferred selectors for URL-backed matches.

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

Conciseness5/5

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

The purpose is front-loaded in the first sentence, and the second sentence efficiently covers behavior, return shape, and alternatives. Although dense, every clause adds actionable information for selecting and invoking the tool.

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?

The definition is complete for a search tool with seven well-described parameters, read-only annotations, and an output schema. It covers scope, alternatives, source types, and non-execution behavior without needing to restate return-value structure that the output schema already defines.

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 detailed parameter descriptions already carry most semantic weight. The main description adds some strategic guidance, such as preferring URLs for URL-backed matches, but does not explain the roles of maxResults, caseSensitive, maxLineLength, or excludeMinified beyond what the schema provides.

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: finding known function names, endpoints, literals, tokens, or code patterns in JavaScript sources loaded by the selected debugger context. It clearly scopes the search to the main frame by default or the frame chosen with select_frame, and distinguishes itself from sibling tools by naming alternatives.

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?

Explicitly routes the agent: use select_frame for iframe-specific work, get_script_source for nearby context, save_script_source for whole bundles, set_breakpoint_on_text when runtime values are needed, and get_request_initiator for known captured requests. These are concrete when-to-use and when-to-use-alternative instructions.

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