nodriver-mcp-server

Overview Schema Source Related Servers Discussions Admin

Get computed styles

get_computed_styles

Read-only

Reveal an element's computed styles to pinpoint why it is invisible or unclickable. Returns resolved CSS values, position, size, and viewport presence.

Instructions

Read an element's computed styles, as the browser actually resolved them.

Computed styles are the end result of the whole cascade, so this answers what a stylesheet alone cannot: why an element is invisible (display: none, visibility: hidden, opacity: 0), what a CSS variable resolved to, or which font actually got used.

Also reports the element's box: position, size, and whether it is currently in the viewport. An element with zero width or height is present in the DOM but not rendered, which is the usual reason a click appears to do nothing.

By default only properties that differ from the browser default are returned, because the full set runs to several hundred entries and buries the interesting ones.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`uid`	No	Element uid from the most recent take_snapshot, as an alternative to `selector`. Ignored when `selector` is given.
`browser`	No	Which browser to act on. Each name is an independent Chrome, created on first use. Omit for the shared default; parallel agents each need their own name.	default
`selector`	No	CSS selector of the element to inspect, e.g. "#header" or ".btn.primary". The first match is used. Leave empty to use `uid` instead.
`properties`	No	Only return these CSS properties, e.g. ["display", "color", "font-size"]. Omit to get the properties that differ from the browser default, which is usually what you want — the full computed set is several hundred entries.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.5.0Sep 25, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral detail beyond that: it reports box position/size and viewport status, explains the default filtering of properties (only those differing from browser default) and why (several hundred entries), which is critical for correct use. No contradiction with annotations.

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 a tight set of four short paragraphs, each serving a distinct purpose: core function, explanation of value, box reporting, and default filtering rationale. It is front-loaded with the primary verb and resource. No wasted words.

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?

The description covers purpose, usage context, and key behavioral traits. With an output schema present, the return format is handled. It does not mention error conditions or edge cases (e.g., what happens if the selector matches nothing), but those are typically outside description scope. Overall it is complete for an agent to call this tool effectively.

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 each parameter is already documented. The description adds context about the default behavior of the 'properties' parameter and explains why omitting it is usually best. This adds value but does not significantly change the meaning of the parameters; the schema already carries the load.

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 clearly states the tool reads an element's computed styles as the browser resolved them, and distinguishes it from other tools by emphasizing it answers questions about the cascade (visibility, CSS variables, fonts) and reports box geometry. It is distinct from siblings like evaluate_script or take_snapshot.

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?

The description implies when to use it: to understand why an element is invisible or not clickable, or to resolve computed values that stylesheets alone cannot. It does not explicitly name alternative tools, but the context is clear enough for an agent to decide. A minor gap is the lack of explicit 'do not use when...' exclusions.

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

Deploy Server