Skip to main content
Glama
Agent360dk

Browser MCP

by Agent360dk
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

browser_get_page_content

Retrieve the current page's content as text or HTML. Use a CSS selector to extract a specific section instead of the full page, avoiding oversized responses that are clearly marked when truncated.

Instructions

Get the content of the current page as text or HTML. Pass selector to read one part of a large page instead of all of it - on a big logged-in app the full HTML can run past a million characters. The answer is capped at 30000 characters by default and says so when it had to cut, with the real length, so a truncated page is never mistaken for a whole one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNoOutput format (default: text)
selectorNoCSS selector. Reads only that element instead of the whole page. If it matches nothing the call fails rather than silently returning the whole page.
max_charsNoCap on returned characters (default: 30000). Over the cap the answer carries truncated: true and total_chars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.29.2
    • addedInput schema / properties / max_chars
      Added value: +{
+  "description": "Cap on returned characters (default: 30000). Over the cap the answer carries truncated: true and total_chars.",
+  "type": "number"
+}
    • addedInput schema / properties / selector
      Added value: +{
+  "description": "CSS selector. Reads only that element instead of the whole page. If it matches nothing the call fails rather than silently returning the whole page.",
+  "type": "string"
+}
  2. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It transparently discloses the 30000-character cap, the truncation flag and total_chars field, and the fact that truncation is never silently mistaken for a full page. It also mentions the selector's failure behavior indirectly via the schema, but the description itself does not repeat that. It lacks details on error handling (e.g., page not loaded) but covers the most important behavioral quirk.

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 sentences, front-loaded with the primary purpose, then a targeted usage tip, then a crucial behavioral note. No fluff, every clause earns its place. The structure leads with the core action and immediately addresses the most common pitfall (large pages).

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?

For a tool with three optional parameters and no required ones, the description covers the essential usage scenarios, the truncation behavior, and the selector's purpose. The output schema is absent, but the description explains what the response includes (text/HTML, truncation metadata), so an agent has enough to call it correctly and interpret results.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine value: it explains why the selector exists (to handle very large pages) and gives a concrete size example, and it clarifies the truncation semantics for max_chars. This goes beyond what the schema states, making the tool easier to use correctly.

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 ('Get') and a precise resource ('content of the current page as text or HTML'), and it is immediately distinguishable from sibling tools like browser_screenshot (image capture), browser_extract_list (structured data), or browser_fetch (network request). No ambiguity about what this tool does.

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?

Provides clear contextual guidance on when to use the selector parameter ('read one part of a large page instead of all of it') and explains the rationale with a concrete example (big logged-in app HTML exceeding a million characters). It does not explicitly mention when not to use this tool or name alternatives, but the context implies it is the default for reading page content.

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