JsHookMcp is an AI-powered MCP server providing 500+ tools across 36 domains for JavaScript analysis, security research, browser automation, and reverse engineering.
Meta-Tool Capabilities (always exposed)
search_tools — Keyword/vector hybrid search to discover tools
route_tool — Natural language task router that recommends tools, workflows, and activation order
describe_tool — Retrieve full details and input schema for any tool
activate_tools / deactivate_tools — Dynamically register or remove specific tools to manage context
activate_domain — Activate an entire domain at once (e.g., browser, network, debugger) with optional auto-expiry
call_tool — Execute any active tool by name
Broader Capabilities (accessible after activation)
🌐 Browser Automation — Chromium/Camoufox control, CDP debugging, anti-detection, CAPTCHA handling
📡 Network Interception — HTTP/2 traffic monitoring, MiTM capture, GraphQL analysis, Burp Suite bridge
🪝 JavaScript Analysis — JS hooks, AST transforms, source-map reconstruction, deobfuscation
🧠 AI-Driven Code Analysis — LLM-powered deobfuscation, crypto detection, AST comprehension
🔍 Reverse Engineering — WASM disassembly, binary analysis, Frida/Ghidra/IDA integration
🧰 Process & Memory Forensics — Native FFI scanning, hardware breakpoints, PE introspection
🔄 Dynamic Extensibility — Declarative workflows, hot-reload plugins, cross-domain orchestration
🛡️ Security Research — Exploit development, syscall hooks, protocol analysis, encoding utilities
Provides a bridge for Burp Suite, enabling integration with the Burp Suite security testing platform for network interception and analysis.
Provides GraphQL introspection capabilities for analyzing and querying GraphQL APIs.
A search-first, profile-aware reverse-engineering workspace for AI agents.
Hook the page, capture the network, deobfuscate the bundle, disassemble the WASM, instrument the process — and let one MCP server keep the whole attack surface in reach without drowning the model in schemas.
English · 中文
Most MCP servers for JS analysis expose a handful of hand-rolled tools or wrap a single browser engine. jshook is closer to an operating system for front-end reverse engineering — 34 self-discovered domains, a search-first meta-tool that keeps token cost under control, and runtime recovery that survives broken pages and dropped sessions:
Search-first, profile-aware. The search profile loads about 3K tokens of tool metadata; the full profile exposes all 723 tools at around 40K tokens. Agents move between them as the task grows — search → workflow → full — instead of drowning in schemas from the first turn.
Runtime recovery and session isolation. Streamable HTTP sessions restore activated domains, browser attach state, and coverage state after reconnects; per-client browser-side state stays isolated so two agents cannot trample each other's CDP sessions.
Full-stack browser automation. Chromium and Camoufox via CDP with anti-detection, an explicit-input CAPTCHA solver (no built-in page/feature probing), a self-signed HTTPS interception CA on demand, and HTTP/2 frame building.
Real reverse engineering, not string searches. WASM disassembly via Binaryen, Frida/Ghidra/IDA bridges, native FFI scanning, hardware breakpoints, PE introspection, GraphQL/Burp Suite proxy bridges, and AST transforms — not a single regex call wrapped as a tool.
Dynamic extensibility. Hot-reload plugins, declarative workflows, and auto-discovery keep the server growing without a redeploy.
Related MCP server: claw-mcp-toolkit
A scan of what's in the box. Each row links to the detailed Capability overview below.
Area | Highlights |
Tool profiles |
|
Browser automation | Chromium and Camoufox · CDP attach to existing targets · anti-detection presets · explicit-input CAPTCHA solver · popup, download, permission, and protocol interceptors |
Network interception | HTTP/1.1 + HTTP/2 frame building · MITM proxy with auto-generated CA · WebSocket capture · GraphQL introspection helpers · Burp Suite bridge |
JS hooks and analysis | LLM-powered deobfuscation · crypto routine detection · AST comprehension · source-map reconstruction · script/scriptlet extraction and replay |
WASM reverse engineering | Binaryen disassembly · module inspection · import/export analysis · cross-reference graphs · runtime instrumentation |
Process and memory forensics | Native FFI scanning · hardware breakpoints · PE introspection · live process attach · memory read/write with region guards |
Binary instrumentation | Frida bridge · Ghidra and IDA bridges · syscall hooking · BoringSSL inspector · BoringSSL/Mojo IPC analysis |
Native runtime | Native emulator for foreign-architecture samples · platform introspection · Mojo IPC · Dart Inspector · ADB bridge for on-device traffic |
Encoding and transform | URL/Base64/Hex/JWT/Protobuf encoders · AST transforms · streaming decode pipelines |
Coordination | Background task queue with progress, cancellation, and async modes · multi-agent coordination · coverage reports |
Schema-first meta tools |
|
Pluggable extension registry | Hot-reload plugins · declarative workflows · auto-discovered domains |
Scenario | What you do | Domains involved |
Skim a minified bundle |
|
|
Reverse a CAPTCHA challenge | Drive a Camoufox page → screenshot → solve with explicit input → replay |
|
Capture and replay an OAuth flow |
|
|
Reverse a WASM crypto routine |
|
|
Recover a dropped browser session | Reconnect Streamable HTTP → restore activated domains and browser state |
|
Audit a Node process for credentials |
|
|
Build a custom workflow |
|
|
Hook a function in a live process | Frida script → |
|
No global install needed — add to your MCP client config and you're ready.
Claude Desktop / Cursor (claude_desktop_config.json):
{
"mcpServers": {
"jshook": {
"command": "npx",
"args": ["-y", "@jshookmcp/jshook@latest"],
"env": {
"MCP_TOOL_PROFILE": "search",
"npm_config_omit": "optional"
}
}
}
}(Windows: use npx.cmd absolute path if npx is not found.)
This lightweight configuration skips optional ONNX, Z3, Binaryen, Camoufox, and Playwright
packages. Remove npm_config_omit when those full-profile runtimes are required.
The default stdio configuration starts one full jshook process per MCP host. To share the embedding model, browser runtime, and caches, start one local Streamable HTTP daemon:
pnpm build
pnpm daemonVector search defaults to off for per-client stdio processes and on (lazy-loaded) for the shared
HTTP daemon. Set SEARCH_VECTOR_ENABLED=false when lexical search is sufficient.
Then point every MCP client at http://127.0.0.1:3000/mcp using its HTTP/URL server
configuration. Each client receives its own MCP session and response route while heavyweight
runtime resources remain in one process. Keep the default loopback bind; set MCP_AUTH_TOKEN
before exposing the endpoint beyond localhost.
{
"env": {
"MCP_TOOL_PROFILE": "search" // start here, ~3K tokens of metadata
}
}Switch MCP_TOOL_PROFILE to workflow once you start chaining composite scripts, or to full
when you need every tool. coverage_report shows the active set on demand.
Profile ladder. Start in search (~3K tokens of metadata); promote to workflow when chaining composite scripts; escalate to full only when every tool is actually needed. coverage_report shows what's active on demand.
Meta tools. describe_tool returns the JSON Schema; call_tool validates arguments before invocation; every tool ships with readOnlyHint / destructiveHint / idempotentHint / openWorldHint.
Browser automation. Chromium and Camoufox via CDP, attach to existing targets, anti-detection presets, popup/download/permission interceptors, explicit-input CAPTCHA solver, JS/CSS injection at three document phases, persisted coverage across reconnects.
Network interception. Auto-generated HTTPS interception CA, HTTP/1.1 + HTTP/2 frame building, WebSocket capture, GraphQL helpers, Burp Suite bridge — all on the same MCP tool surface.
Reverse engineering. Binaryen WASM disassembly, Frida/Ghidra/IDA bridges, hardware breakpoints, native FFI scanning, PE introspection, syscall hooking, AST transforms, source-map reconstruction.
Session recovery. Streamable HTTP transport restores activated domains, browser attach state, and coverage state after reconnects; browser-side state is isolated per client.
Plugins and workflows. Drop a directory, get a domain. Write a YAML pipeline, run it as one tool. The registry self-discovers.
The server supports two transports out of the box.
Transport | When to use | Notes |
stdio | Default for Claude Desktop, Cursor, and other single-host clients | One full process per MCP host; lightweight profile recommended |
Streamable HTTP | Multiple agents sharing the embedding model, browser runtime, and caches | Loopback bind by default; set |
Both transports expose the same tool surface. coverage_report shows which domains are
activated in each session — long-running sessions restore browser attach state, coverage state,
and tool activations across reconnects.
For production deployments see the Security and Production guide.
HTTP transport now multiplexes independent MCP sessions and restores runtime state after reconnects.
proxy_start auto-generates a local HTTPS interception CA when needed.
Browser CAPTCHA solving is now explicit-input driven: pass taskKind, siteKey, imageBase64, callbackName, and responseSelector as needed. Built-in widget/page signature probing is intentionally not used.
The built-in surface below is generated from the runtime registry and checked in CI.
Package version: 0.3.5
Built-in tools: 723
Domains: adb-bridge, binary-instrument, boringssl-inspector, browser, canvas, coordination, core, cross-domain, dart-inspector, debugger, encoding, exploit-dev, extension-registry, graphql, instrumentation, maintenance, memory, mojo-ipc, native-bridge, native-emulator, network, platform, process, protocol-analysis, proxy, sourcemap, streaming, syscall-hook, tasks, trace, transform, v8-inspector, wasm, webgpu, workflow
Note: this snapshot is generated from the runtime registry; do not edit the counts by hand.
Runtime registry — domains auto-discovered via manifest.ts; add a domain by creating one file.
Lazy initialization — handlers instantiated on first call, not at startup.
BM25 + vector search — search_tools meta-tool with hybrid ranking and adaptive weights.
MCP ToolAnnotations — every tool carries readOnlyHint / destructiveHint / idempotentHint / openWorldHint.
Profile ladder — search (~3K tokens) → workflow (composite scripts) → full (all 723 tools).
Transport symmetry — stdio and Streamable HTTP expose the same surface; sessions are isolated per client.
See the Architecture guide and Configuration reference for the canonical details.
Requirements: Node.js 22.12+, pnpm 10.x.
pnpm install
pnpm build
pnpm start # run the built server from dist/
pnpm dev # run from source under tsx watch
pnpm check # metadata check + lint + format check + typecheck + unit tests
pnpm test # Vitest unit suites
pnpm test:e2e # end-to-end browser/tooling suites
pnpm daemon # run the Streamable HTTP daemon after buildNative helpers are bundled via pnpm build; on first run the server may download optional
runtimes (ONNX, Z3, Binaryen, Camoufox, Playwright) depending on the profile.
Activate all tools in a domain at once. Domains: . Use reload_extensions first to include external plugin/workflow domains.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Domain name to activate (e.g. "debugger", "network") | |
| ttlMinutes | No | Auto-deactivate after N minutes (default: 30, set 0 for no expiry) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the burden of disclosing behavior. The description only states the basic action and a prerequisite, but does not mention any side effects, permissions, or reversibility of activation. It also has a broken placeholder 'Domains: .'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (2 sentences), but includes a confusing broken fragment 'Domains: .' which detracts from conciseness. It is front-loaded with the main action but ends with an incomplete thought.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context, such as the list of available domains or what 'activation' entails. It fails to do so, leaving the user uncertain about the domains that can be activated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, so the description does not need to add much. It does not elaborate on the parameters beyond the schema, so it meets the baseline for no added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Activate all tools in a domain at once.' It distinguishes from siblings like 'activate_tools' (which likely activates individual tools) by specifying it operates on a whole domain. However, the incomplete sentence 'Domains: .' reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a prerequisite: 'Use reload_extensions first...', which implies when to use it. But it does not explicitly contrast with alternatives like 'activate_tools' or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dynamically register specific tools by name, regardless of current base tier. Use after search_tools to enable exactly the tools you need. In search-tier sessions this is usually enough; you do not need boost_profile just to use a few exact tools. Activated tools appear in the tool list immediately. If tools do not appear after activation, use call_tool to invoke them directly.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Array of tool names to activate (from search_tools results) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses that activation makes tools appear immediately and suggests direct invocation if not. Lacks details on side effects or permissions, but adequately covers expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Multiple sentences but no waste; core action front-loaded. Could be slightly shorter, but structure is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple input, no output schema, the description explains activation behavior, usage pattern, and recovery step, making it fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context by referencing search_tools as source for names, reinforcing parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool dynamically registers tools by name, and distinguishes from siblings like search_tools and call_tool. It also compares to boost_profile, providing clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use after search_tools, notes it's usually enough without boost_profile, and provides fallback using call_tool if activation fails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute an already-active tool by name. Use this when activate_tools/activate_domain registered a tool but your client did not refresh its tool list. Does not auto-activate inactive tools.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The tool name to execute (from search_tools or describe_tool results) | |
| args | No | Arguments object to pass to the tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behaviors. It only states it executes active tools and does not auto-activate, omitting error handling, auth needs, rate limits, or what happens if tool not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main purpose and usage context, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core purpose and limitation but lacks details on error cases, return value, or validation of args. Given no output schema, more behavioral context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for both parameters (name and args), so the description adds little beyond schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'execute' and resource 'already-active tool', and distinguishes from sibling tools like activate_tools and deactivate_tools by specifying it does not auto-activate inactive tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (after activation when client didn't refresh) and implies when not to use (tool not active). Could mention alternatives like activate_tools for inactive tools, but is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove previously activated tools to free context. Only affects tools added via activate_tools, not base profile tools.
| Name | Required | Description | Default |
|---|---|---|---|
| names | Yes | Array of tool names to deactivate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool removes tools and frees context, but does not mention side effects, permissions, or reversibility. The behavioral transparency is adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one required array parameter) and no output schema, the description adequately explains the tool's effect and scope. It is complete for the tool's straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'names' parameter: 'Array of tool names to deactivate'. The overall description adds context that these are tools activated via activate_tools, but this is already implied by the tool's purpose. The schema does the heavy lifting, so the description adds limited additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes previously activated tools to free context, specifying the verb 'remove' and the resource 'previously activated tools'. It distinguishes from siblings by clarifying it only affects tools added via activate_tools, not base profile tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that the tool only affects tools added via activate_tools, not base profile tools, providing clear guidance on when to use it. It implies it is the counterpart to activate_tools, but does not explicitly mention alternatives or when not to use it beyond that scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific tool, including its input schema. Use this to see the exact parameters a tool expects before calling it.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Tool name to describe |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description accurately states it retrieves tool info and input schema, but offers no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with purpose, no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple tool with one parameter and no output schema; could mention return format but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter 'name' already described in schema (100% coverage); description adds no extra meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and resource 'detailed information about a specific tool', distinct from sibling tools like call_tool or search_tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests using before calling another tool to inspect parameters, but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-stop tool router: accepts a natural language task description, returns recommended tools and next actions. Automatically detects workflow patterns, recommends activation order, and provides example arguments. Use this instead of search_tools when you want guided tool discovery with actionable next steps.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | Natural language description of the task you want to accomplish | |
| context | No | Optional context hints for routing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries behavioral disclosure. It explains that the tool detects workflow patterns, recommends activation order, and provides example arguments, going beyond simple I/O to explain internal processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with clear front-loading: first sentence defines purpose, second sentence adds usage guidance. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description mentions 'returns recommended tools and next actions' but lacks details on output format, structure, or how to interpret results. For a tool whose primary output is recommendations, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for 'task' and 'context'. Description does not add further semantic detail beyond what schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool is a router that accepts a task description and returns recommended tools/actions. It explicitly distinguishes from sibling search_tools, providing specific verb+resource: natural language task to tool recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this instead of search_tools when you want guided tool discovery with actionable next steps', providing clear context for when to use this tool. Could be stronger by stating conditions for using alternatives like search_tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search 0 tools across 0 capability domains. This includes built-in tools plus any loaded plugin/workflow tools (0 currently loaded). In search-tier sessions, call this before assuming a capability is unavailable. Use activate_tools for exact matches, activate_domain for an entire domain. Domains: . Query tip: before searching, distill your intent into key concepts (action verb + target + domain). Pass distilled keywords, not full sentences — the search engine works on token matching, not semantic understanding.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Before calling, distill your intent into 2-5 key concepts: what action, on what target, in which domain. Pass only those distilled keywords — not the original user request. | |
| top_k | No | Max results to return (default: 10, max: 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds behavioral context: it explains how the search engine works ('token matching, not semantic understanding') and provides a query formulation tip. However, it does not disclose potential limitations or exact return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with multiple sentences. While each sentence provides useful information, it is slightly verbose and could be more streamlined. However, it is still relatively concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description covers purpose, usage guidance, query optimization, and sibling differentiation. It lacks details on result structure or pagination, but overall it is fairly complete for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description adds value beyond schema by providing guidance on how to construct the query parameter (distill intent into key concepts) and clarifying the default and max for top_k. This adds meaning not present in the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as searching tools across capability domains, including built-in and plugin/workflow tools. It distinguishes itself from sibling tools like activate_tools and activate_domain by specifying that it is for searching, not activating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use this tool: 'In search-tier sessions, call this before assuming a capability is unavailable.' It also provides alternatives: 'Use activate_tools for exact matches, activate_domain for an entire domain.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.3.0activate_domainactivate_toolscall_tooldeactivate_toolsdescribe_toolroute_toolsearch_toolsScored across 7 tools
Tools have mostly distinct purposes, but activate_domain and activate_tools overlap in activation functionality, and route_tool overlaps with search_tools in discovery. Descriptions help differentiate.
All tools follow a consistent verb_noun pattern (e.g., activate_domain, search_tools), making predictions easy.
7 tools is well-scoped for a tool management server, covering all necessary operations without being excessive.
Covers activation, deactivation, search, description, routing, and calling. No obvious gaps in the tool management lifecycle.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Anonymous webhook capture, inspection, waiting, and response configuration for AI agents.
Agents-first viral-hook engine: generate, score, and remix short-form hooks over MCP.
AI-callable tools for API mocking, testing, monitoring, security, and automation.
Universal AI API Orchestrator — 1,554 tools, 96 services. One install.
