blueprint-modular
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_componentsA | Liste les composants du design system Blueprint Modular (nom + description en une ligne). À UTILISER pour parcourir le catalogue ou découvrir ce qui existe dans une catégorie donnée. Résultat paginé par curseur (réutiliser 'nextCursor' pour la page suivante). Catégories : Affichage de données, Feedback, Graphiques, IA & Spécialisés, Identification & traçabilité, Interaction, Mise en page, Média, Navigation, Utilitaires. |
| search_componentsA | Recherche les composants pertinents pour une requête en texte libre (match sur nom, description, catégorie et tags), triés par pertinence. À UTILISER quand on cherche un composant par fonction ou mot-clé (ex. 'tableau triable', 'graphique', 'upload fichier'). Résultat paginé par curseur. |
| get_componentA | Retourne le détail complet d'un composant : description, props/types, exemple d'usage, composants associés/parents et couche sémantique (rôle, frame Ω, type d'indicateur, directionnalité, guidance agent — valeurs proposées, ontologie curée par l'humain). À UTILISER après list/search pour obtenir la signature exacte ET le sens du composant avant de générer du code. Le nom accepte 'bpm.metric' ou 'metric'. |
| suggest_compositionA | Suggère une liste de composants Blueprint Modular répondant à un besoin décrit en langage naturel, en raisonnant sur la couche sémantique (rôle, frame Ω, guidance) : chaque suggestion explicite son sens (meaning) et ses associations sémantiques (pairWith). À UTILISER pour partir d'une intention d'écran (ex. 'un dashboard avec des métriques et un graphique') et obtenir les briques pertinentes. Réponse bornée. |
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 are mostly distinct: list_components and search_components both return component lists but differ in browsing vs. keyword search, and their descriptions clearly define when to use each. get_component and suggest_composition serve unique roles, so confusion is minimal.
All tool names follow a consistent verb_noun pattern with lowercase and underscores: list_components, search_components, get_component, suggest_composition. The slight variance in nouns (components, component, composition) is semantically justified and does not break the pattern.
Four tools is well-scoped for a design system component catalog: browse, search, fetch details, and semantic composition suggestion. Each earns its place and the count feels neither thin nor bloated.
The set covers the full read-only lifecycle of the domain: discovering components (list/search), retrieving deep detail (get_component), and translating an intent into a component set (suggest_composition). No obvious gaps exist for a reference server.