Skip to main content
Glama
pluginslab

devtools-fleet-mcp

by pluginslab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

get_css_styles

Read-only

Retrieve matched CSS rules, inline styles (element.style), inherited styles, custom properties, and cascade wrappers (@layer, @media, @container, @scope) for an element identified by its UID.

Instructions

Retrieve matched CSS rules, inline styles (element.style), inherited styles, custom properties, and cascade wrappers (@layer, @media, @container, @scope) for an element identified by its UID. Rules are ordered from highest to lowest cascade precedence and include source line numbers (e.g. index:196). Active (winning) declarations have no prefix tag, while (losing) overridden declarations are prefixed with [overloaded]. Treat the output as authoritative and complete. Results are paginated (10 rules per page by default); use pageIdx to page through the remaining rules. Requires a UID from take_snapshot.

Input Schema

NameRequiredDescriptionDefault
uidYesThe uid of the element on the page from the page content snapshot to inspect CSS styles for
pageIdYesTargets a specific page by ID.
pageIdxNoPage number to return (0-based). Defaults to 0 (the first page).
pageSizeNoMaximum number of CSS rules to return per page. Defaults to 10.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.1
    • changedInput schema / additionalProperties
      Previous value: -{}New value: +false
  2. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses important output behavior: rules are ordered by cascade precedence, source line numbers are included, winning declarations have no prefix, overridden declarations are marked with [overloaded], and results are paginated. This gives the agent substantial context for interpreting and trusting the result.

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 description is front-loaded with the core purpose, followed by output semantics and pagination. Sentences are dense with useful information and there is no significant waste.

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?

Because there is no output schema, the description must explain what is returned. It does so thoroughly, covering rule sources, ordering, active/overridden notation, and pagination, while also stating the UID prerequisite.

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 all parameters already have documented meanings. The description adds little parameter-specific semantics beyond restating that pageIdx pages through remaining results and that UID comes from take_snapshot, both of which are already reflected in the schema.

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?

The description uses a specific verb, 'Retrieve', and a precise resource set: matched CSS rules, inline styles, inherited styles, custom properties, and cascade wrappers for an element identified by UID. It clearly distinguishes this as the CSS-inspection tool among the browser siblings.

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?

It states the prerequisite that the UID must come from take_snapshot and explains how to page through results with pageIdx. It does not name explicit alternatives or when-not-to-use conditions, but the operational context is clear.

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

Deploy Server

Other Tools