Skip to main content
Glama

Mobbin

by com.mobbin

Search Sections

search_sections
Read-only

Search Mobbin for website sections (e.g. About, Pricing, Footer) using natural language. Returns section images inline along with metadata. Examine the returned images to understand each section's actual content — do not describe or summarize sections based solely on metadata. On hosts that support MCP Apps, also renders an interactive gallery of the results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for paginating through results.
limitNoMaximum number of sections to return. Higher number of sections returned causes increased context usage.
queryYesDescribe one website section in plain language — the content and elements you'd see. Be specific; detail helps. Good: "pricing page with plan comparison table", "hero section with signup form". Avoid: combining multiple sections (search separately), negations, vague style words, disconnected keyword lists.
task_intentNoOne short sentence summarizing the user's overall task. Helps return more relevant results. Write it in English even when the conversation is in another language. MUST be the same across all calls for the same task. Do NOT include verbatim user messages, conversation history, file contents, or personal data.
image_formatNoImage format. Use jpg if your client does not support webp.webp

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes1-based page number of this batch of search results.
queryYesThe natural language query used for this search.
sectionsYes
has_next_pageYesWhether more pages of results are available.

TDQS

A4/5.0
Behavior4/5

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

Annotations already mark the tool read-only and non-destructive; the description adds useful behavior beyond that: images are returned inline with metadata, results must be verified visually rather than summarized from metadata, and an interactive gallery appears on supporting MCP Apps hosts. No contradiction with annotations.

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?

Three focused sentences front-load the purpose, then explain the result-usage rule and the conditional gallery behavior. No filler or repetition of schema content.

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 read-only search tool, the description plus fully documented schema and output schema cover how to call it, what the results look like, and how to handle them. It is slightly incomplete only in not addressing sibling-tool selection or pagination/context-use nuance beyond the schema fields.

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% and the parameter descriptions are already rich, so the description does not need to re-explain parameters. It adds little parameter-specific meaning except emphasizing natural-language querying, which is the baseline expected when the schema carries the load.

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 names a specific verb and resource ('Search Mobbin for website sections') and gives concrete examples (About, Pricing, Footer) that set it apart from the sibling tools searching flows and screens. This is enough for an agent to recognize what this tool is for.

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?

It clearly states natural-language input and instructs inspecting returned images, but it never says when to prefer search_sections over search_flows or search_screens, or when not to use it. The distinction from siblings is left to the tool name and examples rather than explicit usage guidance.

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

All Mobbin toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool searches a distinct content type—flows, screens, and sections—so an agent can clearly choose based on what kind of result is needed. The entity types are separate enough that there is no meaningful overlap or ambiguity.

Naming Consistency5/5

All three tools follow the exact same search_<plural-noun> pattern. This is a perfectly consistent and predictable naming convention.

Tool Count5/5

Three tools is well-scoped for a search-only server. Each tool covers one core Mobbin content category, and none feel redundant or unnecessary.

Completeness5/5

The server's apparent purpose is to search Mobbin's design content, and it covers the three primary content types: flows, screens, and sections. There are no obvious missing operations for this read-only search domain.

Resources