Skip to main content
Glama

get_html

Read-only

Retrieve an element's outer HTML to inspect markup details when text extraction isn't enough. Use selector and character limits to target the exact page fragment.

Instructions

Outer HTML of an element (untrusted page content). Prefer get_markdown; use this for markup details.

Input Schema

NameRequiredDescriptionDefault
offsetNo
selectorNobody
max_charsNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, non-destructive, open-world), but the description adds a genuinely important trait they don't: the returned content is untrusted page content, which flags prompt-injection risk. It doesn't mention truncation/large-output behavior implied by max_chars, so it stops short of a 5.

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 short sentences, zero filler, with the core return value front-loaded and the routing hint immediately after.

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 format needn't be described, and the untrusted-content warning is valuable. But for a 3-parameter tool with 0% schema coverage, an agent still can't tell how offset/max_chars interact with the HTML output (raw offset paging vs truncation), leaving a real gap.

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% and the description only hints at 'selector' via 'of an element'. offset and max_chars — clearly truncation/paging controls on a potentially huge HTML payload — are left entirely unexplained, and defaults (selector=body, max_chars=8000) are never surfaced in prose.

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?

States the specific resource precisely: 'Outer HTML of an element', naming the exact serialization (outer HTML, not inner text or markdown). It distinguishes itself from get_markdown by pointing at markup detail use. Slightly fragmentary and doesn't mention scope (whole page vs element) explicitly, keeping it off a 5.

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?

'Prefer get_markdown; use this for markup details' gives an explicit default and the condition that selects this tool instead. It doesn't address other near neighbors (save_html, get_text, extract_structured), so routing is clear for the main alternative only.

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