Skip to main content
Glama

sb_catalog_search

Read-only

Find an element type by what it does — or OMIT query to browse every type, the only way to meet one you would not have searched for. detail:true adds the AI hints, as does sb_traits_for. query "icon:" lists icon names.

Instructions

Find an element type by what it does — or OMIT query to browse every type, the only way to meet one you would not have searched for. detail:true adds the AI hints, as does sb_traits_for. query "icon:" lists icon names.

Input Schema

NameRequiredDescriptionDefault
limitNoDefault 8
queryNo
detailNoInclude useWhen / avoidWhen / contentTips per match

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.60.1
    • changedInput schema / properties / limit / maximum
      Previous value: -30New value: +60
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
  2. First observedv0.1.4

TDQS

A4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true; the description adds meaningful behavior beyond that — the query-omitted browse mode, that it is the sole discovery path for types you would not search for, and the detail:true effect. It says nothing about return size, limit interactions, or pagination, which keeps it below the top band.

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?

Compact and front-loaded: the primary verb opens the sentence, with browse mode and the detail/icon notes following. Some clauses are tightly packed together, which slightly reduces readability but no sentence is wasted.

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 with no output schema and 3 parameters, the description covers the key non-obvious behaviors: browse-by-omission, detail hints, and special query syntax. Return shape and limit/pagination behavior are unaddressed but are less critical given the readOnlyHint.

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% (query has no description at all). The description compensates by documenting the special query syntax "icon:<word>" and clarifying what detail:true returns (AI hints), which the schema only partially covers via its useWhen/avoidWhen/contentTips note.

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?

The description states a specific verb and resource ("Find an element type by what it does") and gives an agent enough to distinguish it from other search-ish tools. It references sb_traits_for as a related tool, though it does not sharply contrast against the many other siblings in this catalog.

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 gives real usage conditions: omit query to browse every type (the only way to encounter an unsearched-for type), and use detail:true for AI hints. It names sb_traits_for as a related route but stops short of an explicit when-not-to-use rule or a clear boundary between this and unrelated siblings.

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