Canonicalize Tailwind classes to their short form, and search LunarWerx free dev tools.
Scored across 2 tools
The two tools serve completely different purposes - one searches a catalogue of developer tools, the other canonicalizes Tailwind CSS classes. There is no possibility of confusing them.
Both names use lowercase with underscores, but the pattern differs: 'lunarwerx_find_tool' follows company-prefix + verb_noun, while 'tailwind_canonicalize' follows product-prefix + bare verb. With only two tools, there is not enough of a consistent pattern to call it strong.
Two tools is borderline. The find_tool is broad in scope while the Tailwind utility is narrow, making the server feel like an arbitrary pairing rather than a coherent collection.
The server lacks a unified domain; it offers one lookup tool and one code transformation tool. If intended as a LunarWerx surface, it is severely incomplete because only one actual utility is exposed alongside the meta-search.
Search LunarWerx Studios' catalogue of free developer tools and desktop utilities by task or keyword, e.g. "git from my phone", "Windows thumbnails", "voice dictation", "screenshot to UI". Returns what each one does and where to get it. Everything is free; most is MIT-licensed, open source and self-hosted. Products that run an MCP server of their own come back with an "MCP:" line saying how to connect and whether an account is needed, so a match can be used rather than merely reported.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum results (default 5, max 20). | |
| query | Yes | A task, problem, or keyword. Empty returns the whole catalogue. |
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 explains what the return value contains (what a tool does, where to get it), and goes further by describing the 'MCP:' line behavior for MCP-enabled products, including connection details and account requirements. This is valuable context beyond the schema. It does not mention whether the search itself requires auth, but the 'everything is free' note partially addresses this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each earning its place: the first defines the search capability with examples, and the second covers output content, licensing, and the MCP behavior. Information is front-loaded, no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description provides enough context for correct invocation: search scope, query styles, return summary, and a note about MCP-aware results. It lacks explicit mention of authentication requirements or whether it is read-only, but the search nature and free status imply safety. Overall, the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents both parameters fully (100% coverage), including the meaning of an empty query and limits. The description adds example query formats and states that an empty query returns the entire catalogue, which slightly enriches the query semantics. However, this mostly echoes schema information, so it meets the baseline but does not substantially exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb ('Search') and specific resource ('LunarWerx Studios' catalogue of free developer tools and desktop utilities'), and immediately gives concrete example queries that clarify the intended use. It also states what is returned, leaving no ambiguity about the tool's role. The sibling (tailwind_canonicalize) is clearly unrelated, and this description stands on its own.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the usage context explicit: use it when you need to find a tool by task or keyword, with examples illustrating the search style. It does not explicitly contrast itself with the sibling, but there is no evidence the sibling competes with this tool. No exclusions are mentioned, but the use case is clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rewrite Tailwind CSS classes into their canonical short form. Turns arbitrary values back into real design tokens: p-[1rem] becomes p-4, rounded-[24px] becomes rounded-3xl, -bottom-[4px] becomes -bottom-1. Backed by 12,438 replacements generated from Tailwind 4.3.3's own design system, so the answers are authoritative rather than guessed. Handles one class at a time and does NOT merge across classes (px-4 py-4 into p-4, w-6 h-6 into size-6) — that needs the surrounding group to be safe to collapse; use NormWind for that.
| Name | Required | Description | Default |
|---|---|---|---|
| classes | Yes | A Tailwind class string, e.g. the contents of a class= attribute. Whitespace and unrecognized classes are preserved exactly. |
| Name | Required | Description |
|---|---|---|
| result | Yes | The canonicalized class string. |
| changed | Yes | |
| changes | Yes | |
| tailwindVersion | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It does so richly: one-class-at-a-time processing, no cross-class merging, authoritative replacement data from Tailwind 4.3.3, and preservation of whitespace/unrecognized classes via the schema. These traits go well beyond what the structured fields reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence pulls its weight: purpose, concrete examples, data authority, and the critical merging limitation. The core verb and resource are front-loaded, and the description is compact despite covering multiple examples and an alternative tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter transformation tool with an output schema, the description is fully sufficient. It covers expected inputs, behavior, limitations, and alternative routing. No necessary information for an agent to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single `classes` parameter with 100% coverage, so the baseline is 3. The description adds value by illustrating valid input shapes (p-[1rem], rounded-[24px]) and by clarifying operational boundaries like 'one class at a time,' making the parameter's meaning more concrete than the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Rewrite Tailwind CSS classes into their canonical short form.' Concrete examples (p-[1rem] becomes p-4) make the purpose unmistakable and differentiate it clearly from the sibling tool by focusing on canonicalization rather than merging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use context and names an alternative: 'Handles one class at a time and does NOT merge across classes ... use NormWind for that.' This tells the agent exactly which capabilities are excluded and where to route class-merging requests.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lunarwerx_find_tooltailwind_canonicalizeSearch and pull 500+ production-ready React + Tailwind sections and elements
Search Tailwind CSS and React themes, read their tokens and source files, and get download URLs.
Search Wind UI, Magic, Dusk, Telescope and Artisan documentation. Hosted, public, no auth.
Score any URL against a real design contract — 42 checks, A-F grade, token + motion validation.
Add one secure layer between your agents and this server.
