Skip to main content
Glama

components-filter

Filter shadcn/ui components with Tailwind CSS based on specific requirements to find suitable UI elements for your Vue.js projects.

Instructions

filter components with shadcn/ui components and tailwindcss, Use this tool when mentions /filter

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesrequirement json from requirement-structuring tool

Implementation Reference

  • Handler function for the 'components-filter' tool. It takes a JSON requirement string, generates a specialized filtering prompt using getFilterComponentsPrompt, appends an instruction to call the next tool, and returns it as text content for the model to process.
    execute: async (params) => {
      try {
        // 将筛选任务和数据传给 IDE 的 AI 处理
        const filteringPrompt = `${getFilterComponentsPrompt(params.message)}\nAfter outputting the json, call the component-builder tool`;
    
        return {
          content: [
            {
              type: "text",
              text: filteringPrompt,
            },
          ],
        };
      } catch (error) {
        console.error("Error executing tool:", error);
        throw error;
      }
    },
  • Zod input schema for the tool, defining a single 'message' parameter that expects the structured JSON output from the 'requirement-structuring' tool.
    parameters: z.object({
      message: z.string().describe("requirement json from requirement-structuring tool"),
    }),
  • Registration of the 'components-filter' tool on the FastMCP server instance, including name, description, input schema, and inline handler implementation.
    server.addTool({
      name: "components-filter",
      description:
        "filter components with shadcn/ui components and tailwindcss, Use this tool when mentions /filter",
      parameters: z.object({
        message: z.string().describe("requirement json from requirement-structuring tool"),
      }),
      execute: async (params) => {
        try {
          // 将筛选任务和数据传给 IDE 的 AI 处理
          const filteringPrompt = `${getFilterComponentsPrompt(params.message)}\nAfter outputting the json, call the component-builder tool`;
    
          return {
            content: [
              {
                type: "text",
                text: filteringPrompt,
              },
            ],
          };
        } catch (error) {
          console.error("Error executing tool:", error);
          throw error;
        }
      },
    });
  • Supporting helper function that generates the detailed system prompt for filtering shadcn-vue components and charts based on the input requirement JSON, listing available components/charts and enforcing strict output format.
    export function getFilterComponentsPrompt(ui_requirement: string) {
      return `
    SYSTEM ROLE: You are a highly specialized component filtering service with ZERO conversational context awareness.
    
    INPUT SPECIFICATION:
    You MUST receive input in the following EXACT JSON structure":
    ${JSON.stringify(JSON.parse(ui_requirement), null, 2)}
    
    PROCESSING RULES:
    1. You WILL ONLY process the JSON object provided
    2. You WILL IGNORE all conversational text, chat history, or unstructured descriptions
    3. If the input is not in the specified JSON format, respond with: {"error": "Invalid input format. Expected structured JSON."}
    4. You MUST ONLY select components from the AVAILABLE_COMPONENTS list below
    5. DO NOT invent, create, or suggest components not explicitly listed
    
    AVAILABLE_COMPONENTS:
    - accordion: A vertically stacked set of interactive headings that each reveal a section of content.
    - alert-dialog: A modal dialog that interrupts the user with important content and expects a response.
    - alert: Displays a callout for user attention.
    - aspect-ratio: Displays content within a desired ratio.
    - auto-form: Automatically generate a form from Zod schema.
    - avatar: An image element with a fallback for representing the user.
    - badge: Displays a badge or a component that looks like a badge.
    - breadcrumb: Displays the path to the current resource using a hierarchy of links.
    - button: Displays a button or a component that looks like a button.
    - calendar: A date field component that allows users to enter and edit date.
    - card: Displays a card with header, content, and footer.
    - carousel: A carousel with motion and swipe built using Embla.
    - checkbox: A control that allows the user to toggle between checked and not checked.
    - collapsible: An interactive component which expands/collapses a panel.
    - combobox: Autocomplete input and command palette with a list of suggestions.
    - command: Fast, composable, unstyled command menu.
    - context-menu: Displays a menu to the user — such as a set of actions or functions — triggered by a button.
    - data-table: Powerful table and datagrids built using TanStack Table.
    - date-picker: A date picker component with range and presets.
    - dialog: A window overlaid on either the primary window or another dialog window, rendering the content underneath inert.
    - drawer: A drawer component for vue.
    - dropdown-menu: Displays a menu to the user — such as a set of actions or functions — triggered by a button.
    - hover-card: For sighted users to preview content available behind a link.
    - input: Displays a form input field or a component that looks like an input field.
    - label: Renders an accessible label associated with controls.
    - menubar: A visually persistent menu common in desktop applications that provides quick access to a consistent set of commands.
    - navigation-menu: A collection of links for navigating websites.
    - number-field: A number field allows a user to enter a number and increment or decrement the value using stepper buttons.
    - pagination: Displays data in paged format and provides navigation between pages.
    - pin-input: Allows users to input a sequence of one-character alphanumeric inputs.
    - popover: Displays rich content in a portal, triggered by a button.
    - progress: Displays an indicator showing the completion progress of a task, typically displayed as a progress bar.
    - radio-group: A set of checkable buttons—known as radio buttons—where no more than one of the buttons can be checked at a time.
    - range-calendar: A calendar component that allows users to select a range of dates.
    - resizable: Accessible resizable panel groups and layouts with keyboard support.
    - scroll-area: Augments native scroll functionality for custom, cross-browser styling.
    - select: Displays a list of options for the user to pick from—triggered by a button.
    - separator: Visually or semantically separates content.
    - sheet: Extends the Dialog component to display content that complements the main content of the screen.
    - sidebar: A composable, themeable and customizable sidebar component.
    - skeleton: Use to show a placeholder while content is loading.
    - slider: An input where the user selects a value from within a given range.
    - sonner: An opinionated toast component for Vue.
    - stepper: A set of steps that are used to indicate progress through a multi-step process.
    - switch: A control that allows the user to toggle between checked and not checked.
    - table: A responsive table component.
    - tabs: A set of layered sections of content—known as tab panels—that are displayed one at a time.
    - tags-input: Tag inputs render tags inside an input, followed by an actual text input.
    - textarea: Displays a form textarea or a component that looks like a textarea.
    - toast: A succinct message that is displayed temporarily.
    - toggle: A two-state button that can be either on or off.
    - toggle-group: A set of two-state buttons that can be toggled on or off.
    - tooltip: A popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it.
    - typography: Styles for headings, paragraphs, lists...etc
    
    AVAILABLE_CHARTS:
    - area: An area chart visually represents data over time, displaying trends and patterns through filled-in areas under a line graph.
    - bar: A line chart visually represents data using rectangular bars of varying lengths to compare quantities across different categories or groups.
    - donut: A line chart visually represents data in a circular form, similar to a pie chart but with a central void, emphasizing proportions within categories.
    - line: A line chart  visually displays data points connected by straight lines, illustrating trends or relationships over a continuous axis.
    
    ANALYSIS ALGORITHM:
    1. Parse the JSON object
    2. Map functional_requirements to specific component capabilities
    3. Map user_interactions to interaction-capable components
    4. Map data_display needs to appropriate display components
    5. Consider layout_constraints when selecting layout components
    6. Prioritize components by necessity: critical > important > optional
    7. Select MINIMUM viable set - avoid redundancy
    
    OUTPUT FORMAT - RESPOND WITH ONLY THIS JSON STRUCTURE:
    {
      "components": [
        {
          "name": "string (exact match from AVAILABLE_COMPONENTS)",
          "necessity": "critical|important|optional",
          "justification": "string (functional mapping explanation)"
        }
      ],
      "charts": [
        {
          "name": "string (exact match from AVAILABLE_CHARTS)", 
          "necessity": "critical|important|optional",
          "justification": "string (data visualization requirement mapping)"
        }
      ]
    }
    
    VALIDATION RULES:
    - "name" field MUST be exact string match from available lists
    - "necessity" field MUST be one of: "critical", "important", "optional"
    - "justification" field MUST directly reference specific requirement from input JSON
    
    CRITICAL: Your entire response must be a valid JSON object. No explanatory text outside the JSON structure is permitted.
      `;
    }
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions 'filter components' but doesn't disclose behavioral traits like whether this is a read-only operation, what happens to filtered results (e.g., returned, modified, deleted), authentication needs, rate limits, or error conditions. The description lacks essential context for safe and effective use.

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?

The description is brief with two sentences, front-loading the purpose and then usage guidance. There's no wasted text, but it could be more structured (e.g., separating purpose from usage more clearly). It's appropriately sized for a simple tool, though slightly terse.

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 no annotations, no output schema, and a single parameter with good schema coverage, the description is incomplete. It doesn't explain what the tool returns, how filtering works, or the relationship with sibling tools like 'requirement-structuring'. For a tool with implied complexity (filtering components with specific technologies), more context is needed to guide effective use.

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% with one parameter ('message') documented as 'requirement json from requirement-structuring tool'. The description adds no parameter information beyond what the schema provides. With high schema coverage, the baseline is 3, but the description doesn't compensate with additional context about parameter format or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'filter components with shadcn/ui components and tailwindcss' which provides some purpose (filtering components) but is vague about what 'filter' means operationally. It doesn't specify what resource is being filtered (components from where?) or distinguish from sibling tools like 'component-builder' or 'component-quality-check'. The description partially restates the name 'filter' without adding clear differentiation.

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 includes 'Use this tool when mentions /filter' which provides implied usage context based on a trigger phrase. However, it doesn't explicitly state when NOT to use this tool, what alternatives exist among the sibling tools, or clarify prerequisites. The guidance is minimal and relies on pattern matching rather than functional differentiation.

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/HelloGGX/shadcn-vue-mcp'

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