Skip to main content
Glama
1nc0gn30

cwv-speed-engine

by 1nc0gn30

cwv_audit_performance_budget

Audit web page assets against Core Web Vitals budgets, simulate 3G/4G/5G latency, and generate standard Lighthouse budget.json to catch page weight issues.

Instructions

Audit web page assets against Core Web Vitals performance budgets (Scripts, Styles, Fonts, Images), simulate multi-network latency (3G/4G/5G), and generate standard Lighthouse budget.json.

Input Schema

NameRequiredDescriptionDefault
target_nameNoIdentifier or page name for the audit report.Page Budget Audit
html_or_pathYesHTML markup content or path to local HTML file to evaluate.
custom_budgetsNoOptional custom budget limits in KB (e.g. {'script': 150, 'total': 450}).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

B3.2/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden, and it does reveal notable behavior: multi-network latency simulation (3G/4G/5G) and generation of a standard Lighthouse budget.json artifact. However, it omits whether files are written to disk, whether remote URLs are fetched (the schema only mentions local paths), required permissions, and the shape of the audit report, leaving meaningful gaps.

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?

A single front-loaded sentence with three informative clauses and no filler; every clause (audit scope, network simulation, budget.json output) earns its place. Slightly dense as one run-on sentence, but structurally sound.

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?

There is no output schema, so the description must convey return value, and it partially does by naming the Lighthouse budget.json output and the asset categories audited. It still leaves open whether html_or_path accepts remote URLs, how custom_budgets keys map to categories, and what the report contains, which is only adequate for a 3-parameter analysis tool.

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% and all three parameters are documented in the schema, so the baseline is 3. The description mentions budget categories (Scripts, Styles, Fonts, Images) and network profiles but adds no syntax or format detail for html_or_path, custom_budgets, or target_name beyond what the schema provides.

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?

The description names a specific verb (Audit) and resource (web page assets against Core Web Vitals performance budgets) and enumerates the asset categories and network simulation, so the agent knows what the tool does. It does not explicitly differentiate itself from siblings like cwv_audit_site or cwv_diff_performance, which keeps it below a 5.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus the sibling audits (cwv_audit_site, cwv_diff_performance), nor any prerequisites or exclusions. The audit scenario is only implied by the description of outputs.

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