Skip to main content
Glama
Sign In
umbra

umbra

by lxchx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Evaluate

evaluate

Execute JavaScript in a browser tab as a fallback when DOM, text, or ARIA queries cannot retrieve needed data; optionally await promises for async results.

Instructions

Run JS in page (last-resort escape hatch). Prefer dom_query/extract_text/aria_*.

Ex: evaluate('t0', 'document.title') → {"_untrusted":true,"result":"Hacker News"} Ex: evaluate('t0', 'fetch("/api/me").then(r=>r.json())', await_promise=True)

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>",
      "expression": "<expression>"
    },
    "name": "evaluate"
  }
}

Input Schema

NameRequiredDescriptionDefault
tab_idYes
max_charsNo
expressionYes
await_promiseNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It usefully discloses the non-obvious `_untrusted` output wrapper, but says nothing about CSP/sandbox restrictions, whether the expression can mutate page state, what happens on thrown errors or timeouts, or how the promise-await path behaves when the promise rejects.

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?

Three short lines: purpose and routing first, then two illustrative examples. Every element earns its place and nothing is padded.

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, so return shape needn't be spelled out, and the examples cover the two usage patterns well. However, for an arbitrary-code-execution tool with zero annotations, the description omits error behavior, truncation semantics tied to max_chars, and any warning about side effects or detection risk — material gaps for this class of 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 0%, so the description must compensate — it partially does by demonstrating `expression` syntax and `await_promise=True` semantics via two concrete examples, and showing `tab_id` usage. But `max_chars` (default 5000) is never mentioned anywhere, leaving one of four parameters completely opaque.

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?

States a specific verb+resource ('Run JS in page') and immediately characterizes its role in the toolset as a 'last-resort escape hatch'. It names the three siblings (dom_query/extract_text/aria_*) that an agent should reach for first, which no other field provides.

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

Usage Guidelines5/5

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

The parenthetical 'last-resort escape hatch' plus 'Prefer dom_query/extract_text/aria_*' gives an explicit preference ordering against named alternatives. An agent knows both when to consider this and when not to.

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