Skip to main content
Glama
Sign In
Fast Browser MCP

Fast Browser MCP

by kqlio67
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

browser_find_in_page

Find text on a web page to count matches, extract context snippets, and scroll to the first match.

Instructions

Find text on page (Ctrl+F): count matches, extract context snippets, and scroll to first match.

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": {
      "query": "<query>"
    },
    "name": "browser_find_in_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYesText to search for
scroll_to_firstNoScroll to first match

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.8.0

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden, and it does disclose three concrete actions: counting matches, extracting context snippets, and scrolling to the first match. It stops short of describing edge behavior such as case sensitivity, zero-match handling, or the shape of returned snippets.

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?

A single sentence that front-loads the core purpose and packs the three behaviors with zero filler. Every clause earns its place.

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

Completeness4/5

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

For a simple two-parameter tool with no output schema or annotations, the description covers purpose and the main observable behaviors (count, snippets, scroll), which effectively hints at return content. Minor gap: no mention of no-match or case-handling behavior.

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 100%, so both parameters are already documented. The description's 'scroll to first match' maps to scroll_to_first but adds no syntax, defaults, or meaning beyond the schema, making the baseline 3 appropriate.

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 ('Find text on page') and the Ctrl+F analogy anchors it instantly. No sibling in the list performs in-page text search, so it is unambiguously distinct from navigate, snapshot, or get_html.

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?

The Ctrl+F analogy clearly conveys the usage context (searching the currently loaded page) with no need to name alternatives since none exist. However it offers no explicit when/when-not framing, e.g. that it operates on the current tab's rendered DOM rather than source.

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