Skip to main content
Glama
marvkr

Better Design

by marvkr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get UX Design Principle

get-ux-principle
Read-onlyIdempotent

Load UX behavior and product-flow principles on demand before implementing forms, navigation, dialogs, onboarding, microcopy, or positioning. Search by topic, alias, or natural-language query to ground design decisions in concrete guidance.

Instructions

Load UX behavior and product-flow principles into context on-demand.

Use this before implementing flows or interactive behavior: forms, navigation, notifications, errors, dialogs, search, onboarding, responsive behavior, microcopy, positioning, value proposition, rewards and behavior change, design process and clarity audits, motion briefs, interaction patterns, mobile patterns, sound, anti-patterns, understanding users, and cognitive laws / psychology / behavioral science. Writing a landing page headline, value proposition, or any copy that has to say why a product is worth attention: load positioning first, and ask the user for the answers rather than inventing them. Building a catalog, collection page, or product listing: load commerce-catalog. Building a cart, checkout, or payment step: load commerce-checkout. Building a chat, agent, or near-empty prompt-and-response product, or deciding where brand lives once the chrome is gone: load brand-in-sparse-interfaces.

You can either:

  1. Request a specific topic: get-ux-principle({ topic: "behavior-change" })

  2. Use an alias: get-ux-principle({ topic: "reward design" })

  3. Semantic search: get-ux-principle({ query: "confirm progress with control, competence, or recognition" })

  4. Get index of all UX principles: get-ux-principle({})

Use maxTokens to keep responses focused (recommended: 5000–10000).

Input Schema

NameRequiredDescriptionDefault
queryNoNatural language search query to find relevant UX principles.
topicNoSpecific UX topic or alias to load, e.g. forms, navigation, microcopy, positioning, value proposition, reward design, behavior-change, clarity audit, motion brief, design-process, cognitive-laws, psychology, commerce-catalog, commerce-checkout, brand-in-sparse-interfaces.
contextNoOptional. One sentence on WHY you are calling this and what the user asked for (e.g. 'adding nav icons for the fintech dashboard'). Used only for usage analytics; does not change the result.
maxTokensNoMaximum tokens to return. Truncates content to fit. Recommended: 5000-10000.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavior: on-demand loading, truncation via maxTokens, and that 'context' is analytics-only and does not change results. It still says nothing about the shape of the returned content (index vs. article).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the when-to-use block are front-loaded, and the numbered call modes are scannable. The long topic enumeration in the second paragraph is dense and partly redundant with the 'topic' enum-like list already in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-required-parameter read tool with full schema coverage and no output schema, the definition covers when to call it, all four call modes, and budget control. Only the returned format/structure is left unstated, a minor gap given the low complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all four parameters are documented in the schema, giving a baseline of 3. The description adds the empty-call convention ('Get index of all UX principles: get-ux-principle({})') and a maxTokens recommendation, but the alias and semantic-search modes largely restate what the schema descriptions already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Load UX behavior and product-flow principles into context on-demand', with an extensive enumeration of covered subject matter. It does not explicitly separate itself from near-siblings like get-ui-principle or get-motion-guide, which an agent would still have to infer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('Use this before implementing flows or interactive behavior'), lists concrete scenarios, and routes the agent elsewhere for adjacent jobs ('Building a cart, checkout, or payment step: load commerce-checkout'). It also states the pre-condition for positioning work: ask the user rather than inventing answers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools