Skip to main content
Glama

render-mcp

by io.github.RodRomer

inspect_element

Read-only

Answer 'why isn't this element showing where I expect?' for a CSS selector on a live page. Returns the resolved box model, computed display/visibility/opacity/position/z-index, colours, whether the element is inside the viewport, and — crucially — whether another element is covering it. These are the values a browser computes after the full cascade and layout; they cannot be derived from reading HTML and CSS.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlYesThe absolute URL to load, including https://
widthNoViewport width in pixels. 320-2560. Defaults to 1280.
heightNoViewport height in pixels. 240-2000. Defaults to 800.
selectorYesCSS selector for the element to inspect, for example '.buy-button' or '#header nav a'
max_matchesNoHow many matching elements to report. 1-10. Defaults to 3.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.4/5.0
Behavior5/5

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

With readOnlyHint=true already declaring non-destructiveness, the description adds substantial behavioral context: it actually runs a browser, applies the full cascade and layout, and computes visibility-related values including overlapping elements. This goes well beyond the annotations and explains why the tool exists.

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?

Two dense sentences carry a clear purpose and a detailed list of outputs. Nothing is wasted, and the most important use case is front-loaded in the first sentence.

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 adequately explains the tool's output and why it is useful, and the schema covers parameters. It does not describe edge cases like selector-not-found or page-load failures, but for an inspection tool with this level of schema coverage it is largely complete.

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 the schema already documents url, width, height, selector, and max_matches. The description does not add new parameter-level semantics beyond framing selector inspection and live-page context.

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 opens with a specific diagnostic question and names the exact resource (a CSS selector on a live page). It lists concrete computed outputs such as box model, display/visibility/opacity, and occlusion, clearly distinguishing inspection of rendered results from static source reading.

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 question framing gives clear guidance on when to use this tool: when an element is not appearing where expected. It does not explicitly name sibling tools as alternatives, but it implies the right context by emphasizing computed browser values that cannot be derived from HTML/CSS alone.

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

All render-mcp toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool targets a clearly distinct concern: accessibility violations, computed layout, console/network errors, post-JS HTML, screenshots, and PDF output. There is no realistic overlap where an agent would be unsure which tool to call.

Naming Consistency3/5

All names are lowercase snake_case and readable, but the pattern is mixed: inspect_element and screenshot_url are imperative, while accessibility_audit, page_diagnostics, rendered_html, and url_to_pdf are noun-like or descriptive phrases. A uniform verb_noun style would make the set more predictable.

Tool Count5/5

Six tools is a well-scoped count for a render/inspection server. Each tool covers a meaningful, non-redundant capability without bloating the surface.

Completeness4/5

The set covers the core rendered-page workflows: getting content, seeing it, printing it, auditing accessibility, inspecting layout, and diagnosing errors. A minor gap is the lack of interaction or script execution tools, but for the stated rendering/diagnostics purpose the coverage is strong.

Resources