Skip to main content
Glama
Sign In
umbra

umbra

by lxchx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Inspect Element

inspect_element

Retrieve an element's attributes, computed styles, and bounding rectangle to debug layout issues, verify click coordinates, or audit page elements.

Instructions

Attrs + computed style + rect of one element. For debug, click_at coords, audit.

Ex: inspect_element('t0', '#submit') → {"_untrusted":true,"tag":"button","attrs":{...},"rect":{x,y,w,h},"computed":{...}}

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": {
      "tab_id": "<tab_id>",
      "selector": "<selector>"
    },
    "name": "inspect_element"
  }
}

Input Schema

NameRequiredDescriptionDefault
tab_idYes
selectorYes
force_refreshNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.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 behavioral burden. It implies a read-only inspection via the name and example output, but it does not explicitly state side effects, permissions, caching, or what force_refresh changes. The example showing '_untrusted': true adds useful context but is not a full behavioral disclosure.

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?

The description is very short, front-loaded, and includes a concrete example with no filler. However, the telegraphic phrasing ('Attrs + computed style + rect') and unexplained force_refresh keep it from being fully polished.

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?

An output schema exists, reducing the need to explain return values, and the example shows the output shape. But with no annotations and 0% schema description coverage, the definition leaves force_refresh semantics and selector/tab_id formatting underspecified. It is minimum viable but has clear gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for all three parameters. The example shows tab_id and selector usage ('t0', '#submit'), but force_refresh is not explained at all, and no parameter format or behavior is documented beyond the example.

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 clearly states the tool returns attributes, computed style, and bounding rect for a single element, which is a specific verb-plus-resource purpose. It does not explicitly distinguish itself from similar siblings such as dom_query or aria_snapshot, but the output scope is clear.

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

Usage Guidelines3/5

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

It gives implied usage contexts ('For debug, click_at coords, audit') rather than explicit when-to-use/when-not-to-use guidance. No alternative sibling tools are named, so the agent must infer selection from the short list of scenarios.

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