Skip to main content
Glama
iannuttall

Flux UI MCP Server

by iannuttall

search_flux_components

Find Flux UI components by keyword to access documentation and examples from the design system.

Instructions

Search for Flux UI components by keyword

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query to find relevant components

Implementation Reference

  • Primary execution handler for the search_flux_components tool. Validates input, loads component list if necessary, searches cached components, fetches details for matching results if not cached, and formats the response.
    private async handleSearchComponents(args: any) {
      const query = this.validateSearchQuery(args);
    
      try {
        // Ensure components list is loaded
        await this.ensureComponentsListLoaded();
    
        // Filter components matching the search query
         const results = this.searchComponentsByQuery(query);
          console.error(`Search for "${query}" found ${results.length} components.`);
    
        // Consider fetching full details for search results if needed,
        // but for now, just return name and URL like listComponents.
        // Or fetch descriptions if not already cached?
         const detailedResults = [];
          for (const component of results) {
               let details = this.componentCache.get(component.name);
               if (!details) {
                   try {
                       // Fetch details on demand for search results if not cached
                        console.error(`Search cache miss for ${component.name}, fetching...`);
                       details = await this.fetchComponentDetails(component.name);
                       this.componentCache.set(component.name, details); // Cache fetched details
                   } catch (fetchError) {
                        console.error(`Failed to fetch details for search result ${component.name}:`, fetchError);
                       // Use basic info if fetch fails
                       details = component; // Use the basic ComponentInfo from the list
                   }
               }
               detailedResults.push({
                   name: details.name,
                   description: details.description,
                   url: details.url,
               });
          }
    
    
        return this.createSuccessResponse(detailedResults);
      } catch (error) {
         console.error(`Error during search for "${query}":`, error);
         if (error instanceof McpError) {
             throw error;
         }
        this.handleAxiosError(error, `searching components with query "${query}"`);
      }
    }
  • src/index.ts:138-151 (registration)
    Registration of the search_flux_components tool in the ListToolsRequestSchema handler, including name, description, and input schema.
    {
      name: "search_flux_components",
      description: "Search for Flux UI components by keyword",
      inputSchema: {
        type: "object",
        properties: {
          query: {
            type: "string",
            description: "Search query to find relevant components",
          },
        },
        required: ["query"],
      },
    },
  • Input schema definition for the search_flux_components tool, specifying the required 'query' parameter.
    inputSchema: {
      type: "object",
      properties: {
        query: {
          type: "string",
          description: "Search query to find relevant components",
        },
      },
      required: ["query"],
    },
  • Core search logic helper that filters the cached list of components based on the query matching component names.
    private searchComponentsByQuery(query: string): ComponentInfo[] {
      if (!this.componentsListCache) {
        console.error("Attempted searchComponentsByQuery with unloaded cache.");
        return []; // Should have been loaded by ensureComponentsListLoaded
      }
    
      const lowerCaseQuery = query.toLowerCase();
    
      // Prioritize components where the name matches exactly or starts with the query
      const nameMatches = this.componentsListCache.filter(component =>
        component.name.toLowerCase() === lowerCaseQuery ||
        component.name.toLowerCase().startsWith(lowerCaseQuery)
      );
    
      // Then, add components where the description contains the query, avoiding duplicates
      const descriptionMatches = this.componentsListCache.filter(component => {
        // Fetch description if not available in list cache
        // This might require fetching details for all components upfront or on-demand during search
        // For now, we assume description might be pre-fetched or fetched on demand elsewhere
        // Let's refine search to only use name if description isn't readily available
        // Or modify handleListComponents to fetch descriptions initially (slower startup)
        // Sticking to name-only search for now based on list cache content.
        // Revisit if description search is crucial and descriptions are fetched.
        return false; // Temporarily disable description search based on current list cache structure
        // component.description?.toLowerCase().includes(lowerCaseQuery)
       }
      );
    
      // Combine and return
      // return [...nameMatches, ...descriptionMatches];
      return nameMatches; // Return only name matches for now
    }
  • Input validation helper for the search query parameter.
    private validateSearchQuery(args: any): string {
      if (!args?.query || typeof args.query !== "string") {
        throw new McpError(
          ErrorCode.InvalidParams,
          "Search query is required and must be a string"
        );
      }
      return args.query.toLowerCase();
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches by keyword but doesn't cover critical aspects like whether it's read-only, how results are returned (e.g., pagination, format), error handling, or performance considerations. This leaves significant gaps for an agent to understand the tool's behavior.

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?

The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It is appropriately sized and front-loaded, making it easy to parse quickly.

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?

Given the lack of annotations and output schema, the description is incomplete for a search tool. It doesn't explain what the search returns (e.g., list of components, metadata), how results are structured, or any limitations (e.g., search scope, ranking). For a tool with one parameter but no structured output info, more context is needed.

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?

The input schema has 100% description coverage, with the 'query' parameter fully documented in the schema itself. The description adds no additional meaning beyond implying keyword-based searching, which aligns with the schema but doesn't provide extra context like query syntax or examples. This meets the baseline for high schema coverage.

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 clearly states the action ('Search for') and resource ('Flux UI components') with a specific method ('by keyword'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_flux_components' or 'get_flux_component_details', which would require explicit comparison to achieve a perfect score.

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 provided on when to use this tool versus alternatives like 'list_flux_components' (which might retrieve all components without filtering) or 'get_flux_component_details' (for specific component info). The description implies usage for keyword-based searches but lacks explicit context or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iannuttall/flux-ui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server