Applies a TweakCN theme preset to your project by search query or preset ID, with optional dry-run preview and Tailwind v3/v4 support.
Apply a TweakCN theme preset to the project
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search query for theme (e.g., 'cyberpunk', 'modern') | |
| dryRun | No | If true, returns preview instead of writing files | |
| presetId | No | Specific preset ID if known | |
| tailwindVersion | No | Tailwind CSS version (default: '4') |
Changes observed during successful MCP inspections.
v1.1.4Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark this as destructive, but the description adds no additional behavioral context. It doesn't indicate what files are modified, whether the operation is reversible, or what the impact of applying a theme is. Given the destructive hint, the description could have explained the scope of modifications but remains silent, leaving the agent under-informed.
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?
The description is a single, clear sentence with no fluff. It effectively communicates the core purpose without unnecessary words, making it easy to parse quickly. It earns its place by stating the action and target, though it is minimal.
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 destructive action with multiple optional parameters and no output schema, the description is underspecified. It fails to explain what 'apply' does to the project (e.g., which files change, whether dryRun prevents all changes), what the preview in dryRun looks like, or how presetId relates to query. The lack of detail makes it inadequate for safe and effective use.
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?
Schema description coverage is 100%, so all parameters have descriptions in the schema. The tool description adds no extra parameter context. Since the schema fully documents parameters (query, dryRun, presetId, tailwindVersion), the baseline of 3 applies; the description does not hinder or enhance understanding beyond the schema.
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 clearly states the verb ('Apply') and resource ('TweakCN theme preset') and specifies the target ('to the project'). It distinguishes from sibling tools like get_theme or list_themes, which are read-only, but does not detail what 'apply' entails. It avoids tautology and is clear but could be more specific about the nature of the application.
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 provides no guidance on when to use this tool versus alternatives, nor any prerequisites or side effects. It simply states the action without context. There's no mention of when to choose this over get_theme or list_themes, nor any caution about destructive consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.