Skip to main content
Glama

search_components

Search by name or description to find UI components, source code, and coverage matrices across 67 components and 5 frameworks.

Instructions

Search components by name or description

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNoSearch query

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must carry full behavioral disclosure. It only says 'Search', which implies a read operation, but doesn't describe matching behavior (partial/fuzzy), result ordering, pagination, or what happens with an empty query. This is a significant gap for a tool with no annotation safety net.

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, front-loaded sentence with no filler. Every word contributes: the verb, target, and searchable fields are all present, making it maximally concise while remaining informative.

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

Completeness2/5

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

For a simple tool this is thin: the query parameter is not marked required, yet the description gives no clue about calling with an empty query or what the output looks like. Compound that with zero annotations and usage guidance, and the agent is left to guess at core calling expectations.

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?

The schema only says 'Search query' for the query parameter. The tool description adds that the query matches against name or description, giving the parameter meaningful context beyond the schema. Although coverage is 100%, this added semantic value lifts the score above 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?

The description states a clear action ('Search'), a resource ('components'), and the search fields ('name or description'). It is specific enough to distinguish from list_components (list all vs query-based search) and get_component (retrieve specific by ID), though it doesn't explicitly name alternatives.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool versus siblings like list_components or get_component. An agent cannot infer whether search is for free-text exploration or exact lookups, and there is no mention of exclusions, prerequisites, or query optionality.

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