bladewell
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
Bladewell copies Blade + Tailwind CSS v4 components into this Laravel app, where they become the app's own files, used as <x-widget.{name}>. Find components with list_components, read one with get_component (props, slots, examples, Livewire usage) before writing it into a view, and check project_status for what is installed and edited. Before writing the routes a component calls or submits to, read its consider notes in get_component (security, and server cost such as paging and caching): apply what fits the app, and tell the person which you left out. add_components without confirm is a dry run: show the person its file list, and call it again with confirm: true only once they agree. It never overwrites files they edited unless force is true. After installing, the assets need rebuilding (npm run build, or a running npm run dev).
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_componentsA | The Bladewell components, each with its description, group (Forms…), what it requires and whether this app has it installed. Narrow it with query, which matches names and descriptions. |
| get_componentA | Everything about one component: its Blade tags with every prop (default, required, what it does) and slot, its requirements, usage snippets (Livewire included) and working examples. Read it before writing the component into a view. |
| project_statusA | What this app has installed, and which installed files are out of date (a newer version is available), edited by the developer (left alone by updates) or from before bladewell.lock. Also whether the app's Tailwind CSS and Vite are what the components need. |
| add_componentsA | Copies components, and what they require, into this app. Without confirm it is a dry run that writes nothing and lists every file it would create or update; show that to the person, and only call again with confirm: true once they agree. Files the developer edited are skipped unless force is true. Also updates installed components to this version. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
The tools mostly target distinct operations: browsing the catalog, inspecting one component, checking project install state, and adding/updating components. There is some overlap between list_components and project_status because both can reveal installed status, but the descriptions make the intended distinction reasonably clear.
Most names follow a clear verb_noun pattern: list_components, get_component, add_components. project_status is a noun phrase rather than a verb-led name, which is a minor deviation but still readable and understandable.
Four tools is a well-scoped surface for a focused component-library management server. Each tool covers a distinct part of the workflow: discover, inspect, check status, and install/update.
The surface covers the core lifecycle: listing available components, inspecting details, checking installation state, and adding or updating components. A remove/uninstall operation is an obvious minor gap, but most agent workflows can be completed with the existing tools.