@maltjoy/mcp-server 0.3.2 → 0.5.0-beta.0

package/dist/doc/zeroheight/components/2432739/content.md

@@ -0,0 +1,112 @@
+## General guidelines
+
+There are 4 variants to highlight, each with a specific colour and icon, associated with and supporting the nature of the content.
+
+Be careful about the trigger and variant you use in a given context.
+
+- Do: Use the positive and didactic “Information” in a preventive manner to support users take the right steps.
+- Don't: Avoid using warning variants in a preventive manner, before users had the chance to interact with the section.
+
+### Tone
+
+The highlight informs users about important **contextual** messages—use it to alert and guide users in completing ongoing tasks. Highlights should always be placed in direct relation to a specific section or page.
+
+Highlights are **permanent** and can be somewhat intrusive or disruptive to the user experience. Use them only to notify users about high-priority or time-sensitive actions.
+
+Do not use more than one highlight at a time within a given section. If multiple messages need to be communicated, prioritize the most urgent or blocking issue first, or consolidate them into a single highlight.
+
+- Do: Use the right variant and provide immediate help to solve the situation.
+- Don't: Avoid stacking several highlights without a clear link between them.
+
+Do not exceed 2 lines (approximately 130 characters spaces included). ⚠️ **Reduce the length to a maximum of approximately 100 characters on mobile.**
+
+- Do: Write a concise highlight.
+- Don't: Avoid unnecessary details and length.
+
+### Label - optional
+
+Labels are optional. Use label to introduce the highlight’s topic and focus on a primary information.
+
+- Do: Divide the different levels of information between label and subtitle.
+- Don't: Never use the label only.
+- Don't: Never duplicate content in the label and subtitle as it will create noise.
+
+### Links - optional
+
+Links in highlights are optional and should be used sparingly. In some rare cases, users can be redirected to the FAQ, help centre or other sections of the product for additional context on their situation.
+
+- Do: Write a clear, accessible, and actionable link.
+- Don't: Avoid inserting the link on the middle of the highlight.
+- Don't: Avoid adding the link on a single word that may be unseen or unaccessible.
+
+## Information
+
+Information highlights are not system feedback, they are permanent and contextual.
+
+Display them **before** the action is performed to educate users about the current situation, the next steps and how to get there.
+
+- Do: Plan ahead, support before the error.
+- Don't: Never give information too late when you can prevent error from happening.
+
+Use a didactic, slightly joyful tone (when appropriate) but always get right to the topic.
+
+- Do: Engage the user with a light tone, when appropriate.
+- Don't: Depending on your goals and context, avoid being too neutral.
+- Don't: Avoid being overly joyful.
+
+## Warning
+
+Use warnings to alert users about possible errors **before** they occur and provide clear, actionable steps to avoid issues.
+
+- Do: Help the user prevent potential issues and blockers.
+- Don't: Avoid using error highlights when warning are possible.
+
+Keep the message neutral and educational rather than alarming. The tone should be simple and direct.
+
+- Do: Remain neutral.
+- Don't: Avoid being overly alarming.
+- Don't: Avoir merely notifying the user. Focus on prevention and resolution instead.
+
+## Validation
+
+Validation highlights acknowledge a positive event that benefits the user.
+
+This type of highlight reassures users and differentiates from **informational highlights** by confirming a successful outcome.
+
+- Do: Acknowledge successful outcomes—after an autosave, for example.
+- Don't: Don't use informational highlights for validation - they should be displayed before an action is performed.
+
+The tone varies from neutral to slightly joyful but not overly enthusiastic. Reinforce user confidence without unnecessary celebration.
+
+- Do: Add discrete, concise hints of Joy ("All set!", "ready to roll").
+- Don't: Avoid being overly enthusiastic and using interjections (”Woop woop!”), adjectives or adverbs such as “successfully”.
+
+## Error
+
+Error highlights are displayed **after** an issue has occurred, helping users understand what went wrong and how to proceed.
+
+Use error highlights to explain the issue, why it happened, and how to resolve it.
+
+- Do: undefined
+- Don't: Avoid being vague and not providing resolution.
+
+Maintain a clear, neutral, and instructional tone.
+
+- Do: undefined
+- Don't: Avoid dramatic or alarming language.
+
+## AI
+
+The AI-variant focuses on AI-centered and AI-infused features only.
+
+Use a positive, slightly joyful tone—engaging but not overly enthusiastic or overpromising.
+
+- Do: undefined
+- Don't: undefined
+
+Emphasize the specific benefits AI brings to the user in this context, avoiding generic AI advantages.
+
+- Do: Highlight the immediate benefits of AI.
+- Don't: Never use generic and subjective qualifiers.
+
+## Related guidelines

package/dist/doc/zeroheight/components/2432739/description.md

@@ -0,0 +1 @@
+A highlight is a permanent feedback used to draw users' attention to important information. It supports several variants to provide context to the message.

package/dist/doc/zeroheight/components/2432739/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Highlight",
+  "slug": "highlight",
+  "category": "components",
+  "component": "VJoyHighlight",
+  "pageId": 2432739,
+  "pageUid": "2432739",
+  "fetchedAt": "2026-07-15T08:24:45.780Z",
+  "tabs": [
+    "Overview",
+    "Usage",
+    "Content",
+    "🔄 Change log"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/highlight/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/2432739/overview.md

@@ -0,0 +1,17 @@
+![Highlight in client onboarding.](/uploads/51sSxESrIiK8a2IK9DssXA.png)
+
+## Anatomy
+
+## Specifications
+
+## Type
+
+## Size
+
+## Variants
+
+### Desktop
+
+### Mobile
+
+## Related

package/dist/doc/zeroheight/components/2432739/usage.md

@@ -0,0 +1,43 @@
+## Variants
+
+There are 4 variants to highlight, each with a specific colour and icon, associated with and supporting the nature of the content.
+
+### **Deprecation of the default highlight**
+
+The “default” (neutral) highlight was previously used to communicate neutral information without any specific tone. However, we are gradually phasing out its use in new designs.
+
+Our Design System already includes four highlight variants, each with a distinct purpose, colour, and tone (see above). These variants are designed to cover all potential use cases.
+
+Besides, from a UX Writing perspective, a message always carries a tone, as it inherently addresses a user need. Therefore, a fully neutral highlight is not necessary.
+
+#### **Fallback Options**
+
+If you were previously using the default highlight, choose the most appropriate alternative based on the message’s intent:
+
+- **Informational highlight** – for general updates or useful context;
+- **Warning highlight** – for alerts or potential issues;
+- **Validation highlight** - for confirmation and positive outcomes;
+- **Error highlight - **for issues blocking the experience.
+
+## Rules
+
+The highlight has to be used with the accent bar OR icon but **not both.**
+
+- **Accent bar:** Use it to increase the message's visibility.
+- **Icon alignment**: The icon is always aligned with the first line.
+
+## How can I use a highlight
+
+### Highlight or error field?
+
+Highlights apply to broader contexts, not just individual form fields, which require an inline error message.
+
+- Do: Use in-context, specific helper.
+- Don't: Avoid using generic error component for a specific field.
+
+### Highlight or snackbar?
+
+Error highlights should be used instead of a snackbar when the issue requires the user’s focus and prevents further action
+
+- Do: Make sure the error and solution are visible and accessible, especially if it blocks the experience.
+- Don't: Avoid using temporary, not dismissible snackbars that may be unnoticed.

package/dist/doc/zeroheight/components/2434826/change-log.md

@@ -0,0 +1 @@
+## Change log

package/dist/doc/zeroheight/components/2434826/content.md

@@ -0,0 +1,72 @@
+Placeholders should offer **useful and specific guidance** about the expected input. They serve as **hints** to indicate input format or suggest example content, but should not replace labels.
+
+## Placeholder general guidelines
+
+- Keep placeholder text short and concise,** ideally between 3–5 words **(more for free text).
+- Use **simple, familiar language** that is easy to understand.
+- Avoid jargon, full sentences, or overly detailed explanations.
+- Do not overload the placeholder with too much information—keep it focused and clear.
+- **Do not repeat the field label** in the placeholder. Redundancy can confuse users and reduce clarity.
+
+### Accessibility
+
+Avoid truncating placeholder content, as this can negatively impact usability.
+
+- Do: Keep the placeholder within the frame of the field.
+- Don't: Avoid unnecessary lengths.
+
+**Make sure key information to fill the field is accessible outside of the placeholder, as they disappear when users begin typing.**
+
+- Do: Leverage helper text to convey secondary information.
+- Don't: Do not include required instructions solely within the placeholder.
+
+### Types of input
+
+Adapt placeholder content based on the type of input:
+
+- For **action-based fields,** describe the expected written text using **clear and direct verbs ("Search", "Add", "Upload", etc.).**
+
+- Do: Be specific about the action to take.
+- Don't: Avoid generic placeholders.
+
+- Do: Provide additional information about the type of input.
+- Don't: Avoid vague instructions, which offer no contextual guidance.
+
+- For **guidance-based placeholders**, use **examples** (e.g., for dates, emails, phone numbers). However, examples should never replace the label.
+
+- If an example may be misinterpreted as actual input, consider placing it as **helper text below** the input field instead.
+- When using examples within a placeholder, **clearly indicate them by using “Ex:”.**
+
+- Do: Use obvious false or random inputs on top of adding "Ex:".
+- Don't: Avoid confusing the user with seemingly prefilled data.
+
+- Do: Remember to localise placeholder inputs whenever relevant.
+- Don't: Avoid using the same placeholders for all countries.
+
+#### Examples of placeholder usage
+
+| Input Type | Example Placeholder |
+| Name | "First name" |
+| Email | "e.g., [name@domain.com](mailto:name@domain.com)" |
+| Phone Number | "+1 123 456 7890" |
+| Date of Birth | "DD/MM/YYYY" |
+| Username | "Choose a username" |
+| Search Bar | "Search..." |
+## Label usage
+
+- **Always include a label** alongside your input field.
+
+- If a visual label is not present, the placeholder will temporarily act as one. In such cases, a floating or persistent label must appear when the user interacts with the field.
+
+- Do: undefined
+- Don't: undefined
+
+## Placeholder vs. helper text
+
+- **Placeholders** provide short, temporary hints **inside** the input field.
+
+✅ Example: `"e.g., +44 123 4567"`
+- **Helper Text** offers additional instructions and persists **below** the input field.
+
+✅ Example: `"Include country code for international numbers."`
+- If the guidance requires more detail, use **helper text instead of a long placeholder**.

package/dist/doc/zeroheight/components/2434826/description.md

@@ -0,0 +1 @@
+Component description

package/dist/doc/zeroheight/components/2434826/introduction.md

@@ -0,0 +1,15 @@
+## Anatomy
+
+## Size
+
+## Components
+
+### € / %
+
+### Day Month
+
+## Example
+
+![image](/uploads/urmC4wRGXhkHPXAH0HgBxw.png)
+
+## Related

package/dist/doc/zeroheight/components/2434826/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Input Number",
+  "slug": "input-number",
+  "category": "components",
+  "component": "VJoyInputNumber",
+  "pageId": 2434826,
+  "pageUid": "2434826",
+  "fetchedAt": "2026-07-15T08:24:45.803Z",
+  "tabs": [
+    "Introduction",
+    "Content",
+    "Change log 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/input-number/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/2564356/code.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/components/2564356/description.md

@@ -0,0 +1 @@
+Component description

package/dist/doc/zeroheight/components/2564356/introduction.md

@@ -0,0 +1,39 @@
+## Definition
+
+A **modal bottom sheet** must be used to help the user to focus on options, or to give him several choices of actions in a context.
+
+It is an alternative to inline menus or simple dialogs on mobile. They must be dismissed in order to interact with the underlying content.
+
+They may vary according to need and context, by using a number of elements, the composition (list or grid), etc.
+
+### **Size**
+
+Its size may vary depending on the content.
+
+### Natif iOS & Android
+
+On natif, the modal bottom sheet is native component.
+
+### Web
+
+For the web, the modal bottom sheet is working as classic modal
+
+## Anatomy
+
+![image](/uploads/GoVIu0bV9kt7c19Y_WIvEA.svg)
+
+## Overlay
+
+## Components
+
+### Bottom Sheet
+
+### Sticky
+
+### Header
+
+## Examples
+
+![image](/uploads/MGS0MKG7X-i9XHDqKVPW-g.png)
+
+## Related

package/dist/doc/zeroheight/components/2564356/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Bottom Sheet",
+  "slug": "bottom-sheet",
+  "category": "components",
+  "component": "VJoyBottomSheet",
+  "pageId": 2564356,
+  "pageUid": "2564356",
+  "fetchedAt": "2026-07-15T08:24:45.705Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Code"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/bottom-sheet/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/2564356/usage.md

@@ -0,0 +1,14 @@
+## Occurrences
+
+| Composent | Size | Product | Page |
+| Header |  | Transversal | Transversal |
+| Profil Cards |  | Freelance | Search |
+## Title
+
+- Do: null
+- Don't: null
+
+## Title
+
+- Do: null
+- Don't: null

package/dist/doc/zeroheight/components/2849141/content.md

@@ -0,0 +1,114 @@
+## Information architecture
+
+Use this structure:
+
+- **WHAT** – What is this? What’s happening?
+- **SO WHAT** – Why should I care?
+- **WHAT NOW** – What action should I take?
+
+Apply this flow across labels, bodies, and CTAs to ensure a smooth, logical experience.
+
+- Do: WHAT: Use a clear statement to promote the new feature
+- Don't: Avoid detailling the feature's value proposition in the label
+- Do: WHAT: Use a clear statement to promote the new feature - variation with a bit more Joy.
+- Don't: Avoid detailling the feature's value proposition in the label
+
+## Content guidelines
+
+### Media
+
+**Optional**.
+
+Media should support the message, not overshadow it. Match screenshots to the content.
+
+**Format:**
+
+- Avoid iconstrations.
+- Use meaningful, relevant screenshots.
+- For video: use short clips or GIFs, no voiceover.
+
+**Localisation tip:** ⚠️ Avoid embedded text in media. If unavoidable, localise for all languages. Localise visible content, currencies, dates, and fees across all countries.
+
+### Tags
+
+**Optional**.
+
+Only use a tag on the first step; don’t repeat it.
+
+Use the pink **“New”** tag for major feature launches. Use “New” in all languages; do not localise it as “Nouveau”, “Neu”, etc.
+
+Stick to one tag whenever possible. Exceptions:
+
+- **Advanced feature**
+- **AI branding**
+
+If using the **Advanced feature**, show the tour to Starter users only if the feature supports an upsell. Include an upsell option early in the CTAs.
+
+- Do: Use the right colour code for each tag.
+- Don't: Avoid using the neutral tag for specific needs (Advanced feature, AI Search).
+
+### Label
+
+**Mandatory.**
+
+- Do: Always start with a label to emphasise the main information.
+- Don't: Be mindful of the visual hierarchy of information.
+
+- The label is your **WHAT**. It should be clear, slightly joyful at first, but never cryptic. Prioritise clarity over creativity; this is the primary piece of information users will read and remember.
+
+- Do: Write clear, straight-forward labels. Clarity is key!
+- Don't: Avoid phrases, figure of speech or humour that could be misunderstood by the users.
+
+- Try sticking to a maximum of 40 characters in English (≈50 in other languages). Always run Pseudoloc checks to ensure you won't exceed the character limitations in other languages, such as French or German.
+
+- Do: Write short, straight to the point labels.
+- Don't: Avoid adding unnecessary details in the labels. 
+
+- Avoid repetition.
+
+- Do: undefined
+- Don't: undefined
+
+### Body
+
+**Optional.**
+
+- Try not to exceed 2 to 3 lines (≈150 characters).
+- Expands on the **SO WHAT**: how this helps the user and why it matters. State the value proposition clearly. You may add a slight touch of joy to support your statement and boost conversion.
+- Avoid repetition. The body completes the label, it doesn't replicate it.
+
+### Link
+
+**Optional. Use sparingly.**
+
+- Product Tours are, by essence, very contextual. They should keep users focused. Avoid redirecting elsewhere.
+- **If necessary**, include links only to the Help Centre or FAQ, following usual guidelines.
+
+- Do: Leverage the label and body to provide users with just the necessary and relevant level of information.
+- Don't: Avoid redirecting the users to other parts of the product or website, as it will damage the feature conversion.
+
+### CTAs
+
+**Mandatory.**
+
+1. **Main**
+
+- In the first dialog, use joyful, action-driven CTAs like: “Try now”, “Show me”, “Take a look”.
+- Tailor CTAs to the feature: e.g. “Find freelancers with AI”.
+
+- Do: Add some joy and rhythm through engaging CTAs.
+- Don't: Avoid generic, neutral CTAs in the first and last steps of your product tour.
+- Do: If you're promoting an Advanced feature to a Starter user, announce clearly the need to change of service level.
+
+- In following dialogs, keep it concise, prefer “Next”.
+- The final step CTA should drive engagement with the feature.
+
+- Do: undefined
+- Don't: undefined
+
+1. **Secondary**
+
+After step one, the secondary CTA must be “Previous” or “Back”. You may also use it to link to Help or FAQs if relevant.
+
+- Do: undefined
+- Don't: undefined

package/dist/doc/zeroheight/components/2849141/description.md

@@ -0,0 +1 @@
+A promotional and educational component to raise awareness on a newly released feature.

package/dist/doc/zeroheight/components/2849141/meta.json

@@ -0,0 +1,17 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Product tour",
+  "slug": "product-tour",
+  "category": "components",
+  "component": "VJoyProductTour",
+  "pageId": 2849141,
+  "pageUid": "2849141",
+  "fetchedAt": "2026-07-15T08:24:45.860Z",
+  "tabs": [
+    "Overview",
+    "Usage",
+    "Content"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/product-tour/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/2849141/overview.md

@@ -0,0 +1,19 @@
+![Product tour on side navigation](/uploads/reD9vfo_qgBVPwgTB0wbbQ.png)
+
+## Anatomy
+
+## Specifications
+
+## Type
+
+## Responsive
+
+## Components
+
+### Desktop
+
+### Mobile
+
+## Example
+
+## Related

package/dist/doc/zeroheight/components/2849141/usage.md

@@ -0,0 +1,22 @@
+## When to use
+
+Use the Product Tour to announce important new features, only if they’re significant to the business.
+
+Trigger it automatically, centred on the screen, to highlight features that may be hard to discover.
+
+**Optionally**, follow with a series of steps to further educate the user. Each dialog appears on “Next” click.
+
+**Try not** to navigate away from the current page.
+
+Users must be able to exit the tour at any time—and ideally resume it later.
+
+Keep it short: maximum of 5 steps to avoid confusion and drop-off.
+
+Design for progressive disclosure. Plan the full narrative first, then split into clear, actionable chunks—each self-contained and meaningful.
+
+## Overlay
+
+Depending on your context you can use the product tour:
+
+- With overlay
+- Without overlay

package/dist/doc/zeroheight/components/3079912/change-log.md

@@ -0,0 +1 @@
+## Change log

package/dist/doc/zeroheight/components/3079912/content.md

@@ -0,0 +1,35 @@
+## Writing for the group as a whole
+
+- Each ButtonCard in a group must feel meaningfully distinct. If two labels could be confused or swapped, rewrite them.
+- The options should feel exhaustive: users should never feel like their situation isn't covered. If needed, include a catch-all option such as "Create" or "Other".
+- Avoid overlapping subtitles. If two cards say almost the same thing in their subtitle, the options themselves may be too similar.
+- Never write labels or subtitles that imply a hierarchy or a "right answer" unless one genuinely exists. Users should feel confident choosing the option that fits them, not the one that sounds most appealing.
+
+## Anatomy
+
+### **Group label** *(optional)*
+
+- Use when the set of ButtonCards needs a framing question or context that isn't self-evident from the cards alone. Refer to label or titles guidelines.
+- Write as a short, direct question or noun phrase. Example: "What type of account are you creating?" or "Account type", not "Please select one of the following options."
+- Use sentence case. End a question with the appropriate punctuation.
+
+### **Icon**
+
+- The icon should reinforce the label, not decorate it. If the icon doesn't add meaning, omit it.
+- Never use the icon as a substitute for a clear label.
+
+### **Label**
+
+- This is the first thing users read: make it immediately distinguishable from the other options in the group.
+- Write as a short noun phrase that names the path or option. Example: "(ProjectName)"
+- All labels in a group must follow the same grammatical structure.
+- Two to four words is the target. Do not exceed a single line.
+- Use sentence case. Do not end with punctuation.
+
+### **Subtitle**
+
+- Use to clarify or expand on the label, not to restate it.
+- Write as a short complete sentence or a tight noun phrase, depending on what the content requires. Be consistent across all cards in the group.
+- If you're using a sentence, end with a period. If you're using a noun phrase, don't.
+- Keep to one or two lines. If you need more, the option itself may need to be redesigned or split.
+- The subtitle should help users self-select. It answers "is this the right option for me?", not "what happens next."

package/dist/doc/zeroheight/components/3079912/description.md

@@ -0,0 +1 @@
+High-impact navigational element used at strategic intersections to branch a user's flow and reconfigure the subsequent product experience.

package/dist/doc/zeroheight/components/3079912/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "ButtonCard",
+  "slug": "buttoncard",
+  "category": "components",
+  "component": "VJoyButtonCard",
+  "pageId": 3079912,
+  "pageUid": "3079912",
+  "fetchedAt": "2026-07-15T08:24:45.713Z",
+  "tabs": [
+    "Overview",
+    "Usage",
+    "Content",
+    "🔄 Change log"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/buttoncard/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/components/3079912/overview.md

@@ -0,0 +1,11 @@
+![Button card navigation example](/uploads/Jr3hpDKUmIKUiRkk7T53vQ.png)
+
+## Anatomy
+
+## Specifications
+
+## Variants
+
+## Example
+
+## Related

package/dist/doc/zeroheight/components/3079912/usage.md

@@ -0,0 +1,16 @@
+## How to replace the selectable item component?
+
+## Usage
+
+- **Navigation vs. Data:** Use Card Buttons when the choice changes the **user's path** (e.g., choosing a profile type). Use Radio Buttons when the choice merely changes a **data attribute** (e.g., selecting a shipping method).
+- **Interaction Feedback:** The entire card surface must be interactive. To ensure discoverability, use **hover elevations** and a **prominent "Selected" state** (e.g., brand-colored border) to confirm the active path.
+- **Visual Hierarchy:** Card Buttons act as the primary focus of the page. Avoid placing competing Primary CTAs in close proximity; any "Continue" or "Next" actions should be clearly subordinated or placed below the card group.
+- **No Nested Actions:** To maintain click-target clarity, never place secondary links, tooltips, or buttons *inside* a Card Button.
+- **Mandatory Nature:** Because they define the flow's direction, Card Buttons are typically **mandatory**. A selection is required to resolve the intersection and move to the next state.
+
+## Do/don't
+
+- Do: Do use for "Branching" choices that change the layout or flow of the next steps.
+- Don't: Don't use for simple form data (like "A/B") where a Radio button is more efficient.
+- Do: Do make the entire card area clickable 
+- Don't: Don't put a "Submit" or "Continue" button inside the card itself.

package/dist/doc/zeroheight/components/3095627/change-log.md

@@ -0,0 +1 @@
+