Skip to main content
Glama
masaodev

chrome-bookmarks-mcp

by masaodev

Search

bookmarks_search
Read-only

Search Chrome bookmarks by free-text query matching title and URL, or by exact title/URL. Returns results as readable text or raw JSON.

Instructions

Search bookmarks. query = word match against title and URL (Chrome's built-in search). title / url = exact match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoExact URL
queryNoFree-text query
titleNoExact title
formatNoOutput format: text = human-readable list, json = raw BookmarkTreeNode datatext

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, and the description adds matching behavior: query is Chrome's built-in word match, not substring or fuzzy matching, while title and URL are exact. This is useful context beyond the annotation, though it doesn't mention result limits or ordering.

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 compact sentences that are front-loaded and free of fluff. Every clause conveys either the tool's purpose or a meaningful matching distinction.

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?

With optional parameters, fully documented schema fields, a format enum, and a read-only annotation, little is missing for a simple search tool. The absence of an output schema makes a note about return shape desirable, but the format parameter covers the main text-vs-JSON distinction.

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. The description genuinely adds meaning for the query parameter by explaining it as a word match against title and URL, but it mostly restates the exact-match semantics already present in the schema for title and url.

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 and resource ('Search bookmarks') and precisely distinguishes query matching ('word match against title and URL') from exact-match parameters. This clearly differentiates it from retrieval siblings like bookmarks_get and bookmarks_get_recent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use it (keyword search or exact title/URL lookup), but it never names alternatives or exclusion conditions. An agent must infer the boundary with siblings like bookmarks_get_recent or bookmarks_get_tree, so usage guidance is only implicit.

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