awwwards-mcp

Overview Schema Source Related Servers Discussions Admin

analyze_bundle

Read-only

Fetch a live page’s script chunks, save them locally, optionally de-obfuscate, and grep keywords; returns chunk paths and matches so agents can inspect the real animation code.

Instructions

Bundle forensics for a live page: fetch it once, download its script chunks (script tags, inline scripts, and modulepreload/preload-as-script hints; bounded: ≤40 chunks, 10MB, 1 request/second), save them locally, optionally de-obfuscate with webcrack if installed, and grep keywords across the code. Returns chunk paths + match lines so an agent can read the actual animation mechanism instead of guessing. Opt-in bundleIntel adds route, vendor, source-map presence and module-graph evidence; source maps are detected but never fetched, and default output keys are unchanged. Runs on URLs you are authorized to analyze — does not fetch awwwards.com.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "analyze_bundle"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	Absolute page URL whose script chunks to inspect
`edges`	No	static import graph over captured chunks
`keywords`	No	grep these strings across chunks (e.g. class names, effect names)
`maxChunks`	No	default 40
`walkChunks`	No	after the first pass, follow quoted same-origin .js refs inside fetched chunks and fetch up to 20 newly discovered ones (same budgets; adds seconds)
`bundleIntel`	No	opt-in: quoted routes, vendor signatures, source-map presence (never fetched) and module graph; default output keys unchanged

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.15.1Oct 30, 2026
- addedInput schema / properties / url / description
```
Added value: +"Absolute page URL whose script chunks to inspect"
```

Changed2 schema fields changedv1.14.0Oct 28, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / bundleIntel

Added value: +{
+  "default": false,
+  "description": "opt-in: quoted routes, vendor signatures, source-map presence (never fetched) and module graph; default output keys unchanged",
+  "type": "boolean"
+}

Changed1 schema field changedv1.13.0Oct 25, 2026
- removedInput schema / additionalProperties
```
Removed value: -false
```

Changed2 schema fields changedv1.12.0Oct 24, 2026

addedInput schema / properties / edges

Added value: +{
+  "default": false,
+  "description": "static import graph over captured chunks",
+  "type": "boolean"
+}

addedInput schema / properties / walkChunks

Added value: +{
+  "description": "after the first pass, follow quoted same-origin .js refs inside fetched chunks and fetch up to 20 newly discovered ones (same budgets; adds seconds)",
+  "type": "boolean"
+}

Addedv1.11.0Oct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well past the annotations: hard budgets (≤40 chunks, 10MB, 1 request/second), the side effect of saving chunks to local disk, the optional webcrack dependency ('if installed'), the fact that source maps are detected but never fetched, and the promise that default output keys are unchanged. Annotations already cover safety, but this adds cost, side-effect and scope information an agent could not infer.

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 and return value in the first two clauses, and every later clause carries real information (budgets, de-obfuscation, authorization). It is a single dense, semicolon-chained paragraph though, which makes it harder to scan than a short structured form would be.

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

Completeness4/5

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

With six parameters, no output schema and open-world fetching, the description covers returns ('chunk paths + match lines'), rate/size limits, local persistence and the opt-in flag — enough to call it correctly. What is missing is failure behavior (blocked fetches, missing webcrack, truncated budgets) and where the saved files land.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description still adds value: it explains that bundleIntel is opt-in and what it yields (routes, vendor signatures, source-map presence, module graph) and ties the chunk budget language to maxChunks. It does not touch 'edges' or 'walkChunks' in prose, so it is not fully additive.

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?

Names a specific verb and resource ('Bundle forensics for a live page') and then enumerates the exact mechanism: fetch once, download script chunks (script tags, inline scripts, modulepreload hints), de-obfuscate, grep keywords. That level of mechanism detail makes it unmistakable against siblings like analyze_stack or analyze_network_capture without needing to name them.

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

Usage Guidelines4/5

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

Gives a clear motivating context — 'so an agent can read the actual animation mechanism instead of guessing' — plus an authorization constraint ('Runs on URLs you are authorized to analyze — does not fetch awwwards.com'). It does not explicitly route to or away from named alternatives such as analyze_network_capture or analyze_stack, so it stops short of the 5 bar.

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