Skip to main content
Glama
zumerlab

SnapSurf

Official
by zumerlab
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Find text on the page

browser_find
Read-onlyIdempotent

Search text across the WHOLE page (not just the visible part) and get RANKED matches in structuredContent: id, role, name, text (same string, honest label), href (mailto:/tel: pass through intact) and truncated when a value was…

Instructions

Search text across the WHOLE page (not just the visible part) and get RANKED matches in structuredContent: id, role, name, text (same string, honest label), href (mailto:/tel: pass through intact) and truncated when a value was cut. Whole words/phrases rank before incidental substrings. Embedded data hrefs use the same resource/recovery descriptor as browser_open. Optional contextChars allocates a TOTAL text budget to specific relevant sections before broad ancestors, avoiding overlapping context: each included match gets context centered near the first query occurrence with text, totalChars, observationId, offset and prefixOmittedChars (leading text skipped). truncated and a browser_text continuation describe remaining text after the window; read offset 0 for the beginning. Context uses the same frozen first-read text as browser_text; contextMatchesOmitted explicitly counts matches without context; contextOmittedReason and contextCoveredBy explain overlap omissions. The right tool to locate something specific on long pages — do not ask for the full outline.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
sessionIdNooptional: the session this call belongs to (from browser_session_open). Omitted uses the shared default session.
contextCharsNoOptional TOTAL context budget across ranked matches, integer 1–12000 characters. Omitted keeps compact matches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.2
    • addedInput schema / properties / contextChars
      Added value: +{
+  "description": "Optional TOTAL context budget across ranked matches, integer 1–12000 characters. Omitted keeps compact matches.",
+  "maximum": 12000,
+  "minimum": 1,
+  "type": "number"
+}
  2. First observedv0.1.1

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already carry the read-only/idempotent/non-destructive profile, and the description adds substantial behavior beyond them: ranking rules (whole words before substrings), href pass-through, truncation with a browser_text continuation, and the contextOmittedReason/contextCoveredBy/contextMatchesOmitted bookkeeping. This is genuinely useful operational detail an agent could not infer from the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary purpose is front-loaded, which is good, but the body is a single dense block that mixes parameter behavior, output-field inventory, and cross-tool continuation logic. Phrases like 'same string, honest label' and 'resource/recovery descriptor' are cryptic, and the sheer length costs readability even if most clauses carry information.

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?

There is no output schema, so the description rightly enumerates and explains the return fields (id, role, name, text, href, truncated, context, contextOmittedReason). Combined with the ranking and continuation behavior, an agent has everything needed to call and interpret the tool correctly.

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 67% and the description adds real meaning to contextChars beyond the schema: it is a TOTAL budget allocated to specific relevant sections before broad ancestors, with non-overlapping context centered near the first query occurrence. sessionId is left to the schema, so it does not fully compensate for the gap.

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?

The description gives a precise verb+resource ('Search text across the WHOLE page') and scopes it against alternatives by emphasizing whole-page scope and ranked structuredContent. An agent can distinguish it from browser_text (which reads text) and browser_page (full outline) without opening any schema.

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?

It states clear context ('the right tool to locate something specific on long pages') and adds a negative instruction ('do not ask for the full outline'), which routes the agent away from browser_page. It references browser_text for continuation but never names it as the alternative for a plain full-text read, so the when-not guidance is slightly incomplete.

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