Skip to main content
Glama
kznlabs

labsUI

by kznlabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add labsUI items

add
Idempotent

Copy labsUI items and all imported files into your Next.js + Tailwind v4 project, installing their npm packages while keeping existing files intact. Run init first; use dryRun to preview changes.

Instructions

Install labsUI items into the project: copies each item and everything it imports, then installs their npm packages. Existing files are kept, never overwritten. Returns the files written, the packages installed and anything to mount once in the root layout. Needs init first; dryRun previews. To bring installed items to a newer version, use update instead.

Input Schema

NameRequiredDescriptionDefault
namesYesItem names as search lists them, e.g. button or date-picker.
dryRunNoReport what would change, write nothing.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.4
    • changedInput schema / properties / dryRun / description
      Previous value: -"Report, write nothing."New value: +"Report what would change, write nothing."
    • addedInput schema / properties / names / description
      Added value: +"Item names as search lists them, e.g. button or date-picker."
  2. First observedv0.1.3

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (non-read-only, idempotent, non-destructive, open-world), the description discloses the conflict policy ('Existing files are kept, never overwritten'), a side effect the annotations don't convey (npm package installation, consistent with openWorldHint), and what is returned. This is the behavioral context an agent needs before running an installer.

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?

Three tight sentences ordered by importance: what it does, what it will not do, what it returns, then prerequisites and the alternative. No filler and nothing buried.

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

Completeness5/5

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

Although there is no output schema, the description names the return payload (files written, packages installed, root-layout mount instructions). Combined with prerequisites and the sibling routing, an agent has everything needed to call this correctly.

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 coverage is 100%, so both parameters are already documented, including the 'as search lists them' naming convention and dryRun's write-nothing semantics. The description only restates dryRun as a preview, adding no syntax or format detail beyond the schema — baseline 3.

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

Purpose5/5

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

States a specific verb and resource ('Install labsUI items into the project') and then spells out the mechanism — copying each item plus its imports and installing npm packages. This is clearly distinguishable from sibling tools like update, search, and view.

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

Usage Guidelines5/5

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

Gives explicit prerequisites ('Needs init first'), an in-tool alternative mode ('dryRun previews'), and a named sibling for a different intent ('To bring installed items to a newer version, use update instead'). The when-to-use routing is complete.

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

Deploy Server

Other Tools