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.
This server publishes no instructions, or was last inspected before Glama recorded them.
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
Each tool has a clearly distinct role: list_components browses/searches the catalog, get_component gives deep detail on one component, project_status reports the app's install state, and add_components installs/updates files. The list-vs-get split is a well-understood pattern, and status vs install are cleanly separate concerns.
Three of four tools follow a clean verb_noun pattern (list_components, get_component, add_components), all lowercase snake_case. project_status deviates with a noun_noun form without an action verb, a minor inconsistency but still readable and predictable.
Four tools is a tight, focused set that maps cleanly onto the browse-inspect-check-install workflow for a component library. It is slightly lean and a few operations (e.g. removal) are folded into add_components, but each tool earns its place.
The surface covers discovery, detailed inspection, install/update, and environment/status checks, which is most of the lifecycle. The notable gap is that no tool removes or uninstalls components, and update detection is only aggregate via project_status rather than per-component.