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

package/dist/doc/zeroheight/guidelines/1423622/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/guidelines/1423622/description.md

@@ -0,0 +1 @@
+Text input supports users inputing text into the system. This component is highly flexible to adapt to the needs of each application: with or without floating label, bottom cue, icons, or actions.

package/dist/doc/zeroheight/guidelines/1423622/introduction.md

@@ -0,0 +1,29 @@
+![Input example in organization settings](/uploads/vBMDWxNLOSR3P3QtVXLEZg.png)
+
+## Anatomy
+
+Each input can be configured to work with Icons and helper message.
+
+## Type of inputs
+
+## Size
+
+| **Size** | **Height** |
+| LARGE | 64px |
+| MEDIUM | 48px |
+| SMALL | 40px |
+## States
+
+## Helper Text
+
+Helper text gives context about a field’s input, such as how the input will be used. It should be visible either persistently or only on focus.
+
+### Anatomy
+
+![image](/uploads/Q4trYlDXctp-o5jniO3bVQ.png)
+
+### States
+
+#### Error
+
+## Related

package/dist/doc/zeroheight/guidelines/1423622/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Input Text",
+  "slug": "input-text",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 1423622,
+  "pageUid": "1423622",
+  "fetchedAt": "2026-07-15T08:24:45.810Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "Change logs 🔄"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/input-text/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/1423622/usage.md

@@ -0,0 +1,14 @@
+## Usage
+
+The **Input Text** is the primary component for capturing short, single-line strings of data from a user. It is the workhorse of form design, providing a structured way to collect information like names, email addresses, or search queries.
+
+- **Single-Line Focus:** Use only for data that fits on one line. If the user needs to provide a paragraph or detailed feedback, use a **[Textarea](https://joy.malt.com/6bf479565/p/80b38d)** instead.
+- **Clear Labeling:** Every input must have a visible label. Placeholders are not a substitute for labels, as they disappear once the user starts typing.
+- **States & Feedback:** Provide immediate visual feedback for **Focus**, **Error**, and **Success** states to guide the user through the completion of the form.
+
+## Do/don't
+
+- Do: Do use Helper Text below the input to provide specific formatting rules (e.g., "Password must be 8+ characters").
+- Don't: Don't use Placeholder Text to explain complex instructions; it disappears as soon as the user types.
+- Do: Do match the Width of the Input to the expected length of the content (e.g., a shorter width for a Zip Code).
+- Don't: Don't use a text input for data that has a strictly limited set of known options (use a Select or Radio instead).

package/dist/doc/zeroheight/guidelines/1423646/change-log.md

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

package/dist/doc/zeroheight/guidelines/1423646/content.md

@@ -0,0 +1,36 @@
+### Labels
+
+- **Be concise.** Aim for 1–3 words when possible; avoid exceeding one line.
+- **Use sentence case.** Start with a capital letter.
+- **Use parallel structure.** All options in a group should follow the same grammatical pattern.
+- **Make each option distinct.** Users should immediately understand the difference between choices.
+- **Avoid negative phrasings.** An option shouldn’t be another’s negation.
+
+### Group labels
+
+- **Phrase as a statement or question.** Help users understand what they're choosing.
+- **Be specific.** "Payment method" is better than "Options."
+- **Don't end with a colon.** The visual grouping makes the relationship clear.
+
+| ❌ Don't | ✅ Do |
+| Options: | Invoicing method |
+| Select one | How would you like to pay? |
+### Defaults
+
+- **Pre-select an option when appropriate.** Choose the most common, recommended, or safest choice.
+- **Never pre-select options that could cost money or commit the user** without clear intent.
+- **If no logical default exists, leave unselected** and validate that a selection is made.
+
+### Ordering
+
+1. Place the **most common or recommended option first**
+2. Use a **logical sequence** (e.g., price low to high, frequency, size)
+3. If options have equal weight, use **alphabetical order**
+4. Place potentially risky or destructive options **last**
+
+### Accessibility
+
+- **Maintain sufficient color contrast.** Meet WCAG AA ratios.
+- **Never rely on colour alone.** Use a filled circle to show selection.
+- **Provide a visible focus state.** Use a clear outline distinct from the selected state.
+- **Labels must be descriptive on their own.** Users may navigate by form controls (screen readers)

package/dist/doc/zeroheight/guidelines/1423646/description.md

@@ -0,0 +1 @@
+RadioButtons allow a user to select a single option from a list of predefined options

package/dist/doc/zeroheight/guidelines/1423646/introduction.md

@@ -0,0 +1,27 @@
+![Radio button in setting page](/uploads/6oT5myC8aBJb1ehpPCNpDQ.png)
+
+## Anatomy
+
+## Specifications
+
+## Type
+
+## States
+
+### Selected
+
+### Unselected
+
+## Variants
+
+### Atoms radio
+
+### Radio group
+
+#### Horizontal
+
+#### Vertical
+
+## Example
+
+## Related

package/dist/doc/zeroheight/guidelines/1423646/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "RadioButton ",
+  "slug": "radiobutton",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 1423646,
+  "pageUid": "1423646",
+  "fetchedAt": "2026-07-15T08:24:45.875Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "🔄 Change log "
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/radiobutton/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/1423646/usage.md

@@ -0,0 +1,19 @@
+## How to replace the selectable item component?
+
+## Usage
+
+Radio buttons are particularly useful when:
+
+1. Only one option can be selected: Radio buttons are ideal when only one option can be selected, as they force users to choose only one option from a list.
+2. The options are mutually exclusive: When the options are mutually exclusive, radio buttons are a great choice, as they clearly indicate to users which options are available and which option has been selected.
+3. The options are infrequently changed: If the options are infrequently changed, radio buttons are a good choice because they allow users to easily view and change their selections.
+4. The options are related: If the options are related and it makes sense for them to be grouped together, radio buttons are a good way to keep them together and easily accessible.
+5. Space is limited: Radio buttons take up minimal screen real estate, making them a good choice when space is limited.
+
+## Main rules
+
+- Do: Do use when the user must pick exactly one option from a list of two or more.
+- Don't: Don't use if the user needs to select "none"—Radio buttons should always have a default or be mandatory.
+- Do: Do list options in a logical order (e.g., simplest to complex, or cheapest to most expensive)
+- Don't: Don't use for high-impact navigation; it should only store a value within a form.
+- Do: Don't use more than 5-6 options; if the list is longer, consider a Select/Dropdown menu.

package/dist/doc/zeroheight/guidelines/1423650/change-log.md

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

package/dist/doc/zeroheight/guidelines/1423650/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/guidelines/1423650/introduction.md

@@ -0,0 +1,17 @@
+## Anatomy
+
+## Size
+
+## Components
+
+### Close
+
+### Open
+
+When the dropdown is open, we display the Phone input with the **Focus** state
+
+### Elevation
+
+When the dropdown is open we apply the Medium elevation
+
+## Related

package/dist/doc/zeroheight/guidelines/1423650/meta.json

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

package/dist/doc/zeroheight/guidelines/1465972/code.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/guidelines/1465972/content.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/guidelines/1465972/description.md

@@ -0,0 +1 @@
+A tag is a small, labeled element used for categorizing, labeling, or organizing content with key terms or keywords.

package/dist/doc/zeroheight/guidelines/1465972/introduction.md

@@ -0,0 +1,36 @@
+## Anatomy
+
+## Size
+
+| **Size** | **Dimension** |
+| Xsmall | Height : 20px |
+| Small | Height : 24px |
+| Medium | Height : 32px |
+| Large | Height : 40px |
+### Primary
+
+### Primary with Action
+
+#### Removable (draggable)
+
+#### Clickable
+
+### Secondary
+
+### Secondary with icon
+
+#### Removable (draggable)
+
+### Empty
+
+### AI
+
+#### Primary
+
+#### Secondary
+
+### Others
+
+### Strikethrough
+
+## Related

package/dist/doc/zeroheight/guidelines/1465972/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Tags",
+  "slug": "tags",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 1465972,
+  "pageUid": "1465972",
+  "fetchedAt": "2026-07-15T08:24:45.902Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "Code"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/tags/",
+  "extraction": "zeroheight-api"
+}

package/dist/doc/zeroheight/guidelines/1465972/usage.md

@@ -0,0 +1 @@
+

package/dist/doc/zeroheight/guidelines/1476144/change-log.md

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

package/dist/doc/zeroheight/guidelines/1476144/content.md

@@ -0,0 +1,114 @@
+## Tone and voice
+
+- **Be direct:** Minimise the friction and interruption as much as possible.
+- **Be supportive:** Even for error and warnings, stay calm and do not use alarming words.
+- **Be helpful**: If something went wrong, clearly explain what to do next.
+- **Be respectful**: Acknowledge the user's time and autonomy throughout the process.
+
+## **Dialog anatomy**
+
+A dialog typically contains:
+
+1. **Title:** What this dialog is about
+2. **Body:** Context, consequences, or input fields
+3. **Actions:** Primary and optional secondary buttons
+
+### **Title**
+
+Write titles that clearly state the purpose or action.
+
+| **✓ Do** | **✗ Do not** |
+| Delete this proposal? | Are you sure? |
+| Add payment method | Payment |
+| Send Jane a proposal | Send |
+| Withdraw application | Warning |
+**Guidelines:**
+
+- Use sentence case, start with a capital letter.
+- Lead with a verb for action dialogs (Delete, Remove, Cancel).
+- Frame confirmations as questions.
+- Keep titles under 50 characters **in all languages.**
+- Avoid generic titles like “Error” or “Confirmation”.
+- Prefer a matter-of-fact tone most of the time; do not be overly joyful or alarming.
+
+### **Body**
+
+Provide just enough context for users to make an informed decision.
+
+**Guidelines:**
+
+- Avoid adding highlights, links or tooltips within the dialog to divert the user’s attention.
+- Keep body text to 1–3 sentences when possible.
+- Avoid jargon and technical terms.
+- Use a neutral, matter-of-fact tone.
+- Address the user directly, using “you” - when relevant.
+
+#### **For confirmation dialogs:**
+
+Remind the user about the context and the action they’ve just performed. Inform them about the potential consequences of their actions. Follow up with the actions.
+
+*Example: “You are about to delete your quote for 'E-commerce Website Redesign.' This action cannot be undone, and the client will no longer see your submission.”*
+
+#### **For informational dialogs:**
+
+Clarify the context, what has led to the dialog’s display. Inform the users of the next steps.
+
+*Example: “Your identity has been verified. You can now send your quote.”*
+
+#### **For warning and error dialogs:**
+
+Be upfront about the error state - yet reassuring. Explain what is the cause of the situation and how to fix it.
+
+*Example*: “*Your profile isn’t compliant yet. Your quote was saved in the drafts. Upload your proof of identity to get compliant and send out quotes.”*
+
+### **Action buttons**
+
+**Overall guidelines:**
+
+- Never use “Yes”/”No” or “OK”/”Cancel” for destructive actions.
+- Match the button label to the dialog title when possible.
+
+**Primary action (mandatory):**
+
+- Follow the usual guidelines for buttons: “Verb + subject” structure.
+- Use a specific verb that describes the action.
+
+- Examples “Delete proposal”, “Accept quote”, “Submit application”.
+- For destructive actions, use explicit language.
+
+- Example: use “Delete”, “Remove” instead of “Ok”, “Yes”.
+
+**Secondary action (optional):**
+
+- Provide a clear way out: “Cancel”, “Go back”, “Not now”.
+- Or provide a clear alternative to the primary action.
+
+- Example: “Accept application” (primary), “Decline application” (secondary).
+- Use the same terminology as in the rest of the dialog.
+
+- Example: “Delete proposal” (primary), “Keep proposal” (secondary).
+
+### **Accessibility**
+
+**Use clear, descriptive titles**
+
+- Screen readers announce the dialog title first; make it meaningful.
+- Avoid titles that only make sense with visual context.
+
+**Write for cognitive accessibility**
+
+- Use plain language (aim for an 7th-grade reading level).
+- Break complex information into short sentences.
+- Avoid double negatives
+
+- Example: Don’t say “Do not cancel”; instead say “Keep subscription”
+
+**Do not rely on visuals alone**
+
+- Pair colour and illustrations with text labels and written content.
+- Error states should include the word “error” or describe the problem explicitly.
+
+**Provide text alternatives**
+
+- If using icons in buttons, include visible text labels.
+- Decorative images in dialogs should have empty alt text; meaningful images need descriptions.

package/dist/doc/zeroheight/guidelines/1476144/introduction.md

@@ -0,0 +1,41 @@
+## Anatomy
+
+#### Overlay Dialog
+
+#### Full Dialog
+
+### Width
+
+| **Device** | Type | **Size** | **Inside Padding** |
+| Desktop | Overlay | Default - 580pxLarge - 780px | 32px |
+| Mobile | Overlay | Fixed - *Device screen size*- 24 padding | 16px |
+| Desktop | Full Dialog | Full Screen | [Layout page](https://zeroheight.com/6bf479565/p/62355e) |
+### Height
+
+> The heigh of the dialog should wrap the content of it. This means that the heigh of the modal should adapt to the heigh of the content that there is inside of it. Nevertheless, there are some rules for them: the minimum heigh should be 200px so it is easy to notice for the user, the maximum should be 800px so it never exceeds the heigh of the screen itself.
+
+### Multiple dialogs
+
+> If there are more than one dialog in a row (series of dialog, workflow) the size of all of them should be the size of the bigger dialog
+
+### Overlay
+
+## Dialogs Examples
+
+### Desktop
+
+### Mobile
+
+## Brand dialog
+
+⚠ The brand dialog pattern is use **only** for the *brand* or *marketing* related topic
+
+## Scrolling behavior
+
+The max-height is set to 580px max. If the content is bigger than the max-height we activate the scroll behavior.
+
+### Demo
+
+## Signup & login
+
+## Related

package/dist/doc/zeroheight/guidelines/1476144/meta.json

@@ -0,0 +1,18 @@
+{
+  "source": "https://zeroheight.com/6bf479565/",
+  "title": "Dialogs",
+  "slug": "dialogs",
+  "category": "guidelines",
+  "component": null,
+  "pageId": 1476144,
+  "pageUid": "1476144",
+  "fetchedAt": "2026-07-15T08:24:45.734Z",
+  "tabs": [
+    "Introduction",
+    "Usage",
+    "Content",
+    "🔄 Change log"
+  ],
+  "imagesPath": "packages/core-vue/static/zeroheight/dialogs/",
+  "extraction": "zeroheight-api"
+}