Skip to main content
Glama
Sign In

Brandfolder MCP Server and API by Cotlet

by dev.cotlet
OverviewDiscussionsAdmin

Find on the page

cotlet_browser_find
Read-onlyIdempotent

Finds text on the whole current page, frames included: the elements whose label holds it, with their numbers, and each line of text that holds it. Use it instead of reading or scrolling a long page for one thing.

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": {
      "text": "<text>"
    },
    "name": "cotlet_browser_find"
  }
}

Input Schema

NameRequiredDescriptionDefault
appNoLeave it out: the step runs in the user's web browser. Only when cotlet_app_guide names an app's own Cloud Browser, that app's slug, e.g. milanote.
kindNoOnly elements of this kind. Default: any.
textYesWords to look for, any case.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is free to add what they don't: that matching spans the entire page including frames, and that hits come back as labelled elements with numbers and as text lines. That is real behavioral value beyond the structured fields, though it says nothing about ambiguity or multiple-match behavior.

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

Conciseness4/5

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

Two sentences, front-loaded with the action and scope, then the routing hint. The colon-and-list construction after 'frames included' is slightly dense but every clause carries information.

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?

There is no output schema, so the description takes on return-value explanation and does so adequately by describing elements, their numbers, and matching text lines. A minor gap remains: it never explains what the element numbers are for (presumably addressing cotlet_browser_click), which an agent would need to act on the results.

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 coverage is 100%, so the schema already explains `text`, `kind`, and `app` in detail. The description reinforces the page-wide scope of `text` but adds no syntax, matching rules, or case-insensitivity nuance beyond what the schema states, so this sits at the baseline.

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 a specific verb and resource ('Finds `text` on the whole current page, frames included') and goes further by sketching the result shape (elements with their numbers, plus matching text lines). It does not name a sibling explicitly, but the scope statement makes the operation unambiguous.

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?

'Use it instead of reading or scrolling a long page for one thing' names two concrete alternatives (cotlet_browser_read, cotlet_browser_scroll) and the condition that favors this tool. It stops short of stating when this tool is the wrong choice (e.g. when you already know the element's ref).

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

All Brandfolder MCP Server and API by Cotlet toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources