Skip to main content
Glama

get_text

Read-only

Extract visible text from a web page or a CSS-selected element as plain text, prefixed with page title and URL, for reading articles, search results, tables, and status messages.

Instructions

Read-only: return the visible text of the page, or of the first element matching a CSS selector, as plain text. Best for reading articles, search results, table contents and status messages; the text is prefixed with the page title and URL. It carries no element refs: use snapshot when you need to click or type, and screenshot for visual layout. Hidden text is excluded. Output is cut at max_chars; narrow with a selector for long pages.

Input Schema

NameRequiredDescriptionDefault
tabNoTab id from tabs_list. Defaults to the current tab.
selectorNoCSS selector of the region to read (default: the whole body).
max_charsNoMaximum characters to return (default 30000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.2
    • changedInput schema / properties / max_chars / description
      Previous value: -"Max characters (default 30000)."New value: +"Maximum characters to return (default 30000)."
    • changedInput schema / properties / selector / description
      Previous value: -"CSS selector to read (default body)."New value: +"CSS selector of the region to read (default: the whole body)."
  2. First observedv0.1.1

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description still adds real behavioral detail beyond them—output is prefixed with page title and URL, hidden text is excluded, and results are truncated at max_chars. It stops short of describing pagination or error behavior on bad selectors, so not a full 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?

Four tight sentences with the core capability front-loaded, followed by use cases, sibling routing, and the truncation caveat. No filler or restated name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by explaining the return shape (plain text prefixed with title/URL, hidden text omitted, truncated at max_chars). Combined with the annotations, nothing essential for a correct call is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds purpose-level meaning: selector narrows output for long pages and max_chars causes the cut. It does not explain selector syntax edge cases or tab defaulting beyond what the schema states.

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 (return/read) and resource (visible text of the page or a CSS-selected element) with the output format (plain text). It explicitly distinguishes itself from siblings by noting it carries no element refs, pointing to snapshot and screenshot instead.

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?

Gives concrete use cases (articles, search results, tables, status messages) and names the alternatives with the condition selecting each: snapshot for click/type, screenshot for visual layout. An agent can route correctly without inspecting other schemas.

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