# Designesy (pypi · designesy-mcp)

Score any URL against a real design contract — 42 checks, A-F grade, token + motion validation.

- Trust score: 79/100 (medium)
- Change this week: −1
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-09-20

## Components

- remote · `www.designesy.org`: 83/100, [markdown](https://verifymcp.io/servers/le-vai-designesy-org/api-mcp.md), [page](https://verifymcp.io/servers/le-vai-designesy-org/api-mcp)
- pypi · `designesy-mcp`: 79/100 (this document), [markdown](https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp.md), [page](https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp)

## Channel facts

- Registry: `pypi`
- Package: `designesy-mcp`
- Version: `1.12.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-09-20.

- **Supply Chain Security**: 100/100
  - No malware found by supply-chain analysis.
  - No known CVEs affecting this package version or its production dependencies.
  - Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it.
  - No production dependencies, so there is no dependency health to assess.
- **Provenance & Transparency**: 32/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - License check failed: the license (MIT License) isn't a recognized OSI-approved license.
  - Actively maintained (last published 20 days ago).
  - Disclosure check failed: no security disclosure policy was found in the source repository.
- **Schema Quality & AI Usability**: 82/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4278 tokens (~178/item across 24 items; 17 tools + 7 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 93/100
  - Stability observed for 28 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 17 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 18 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 20/100
  - Spec-recency check failed: implements MCP spec 2024-11-05; the latest is 2026-07-28.

## Install

### How do I install the Designesy MCP server?

Designesy runs locally as a PyPI package, launched with uvx designesy-mcp. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add le-vai-designesy-org -- uvx designesy-mcp
```

### Cursor

```json
{
  "mcpServers": {
    "le-vai-designesy-org": {
      "command": "uvx",
      "args": [
        "designesy-mcp"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "le-vai-designesy-org": {
      "command": "uvx",
      "args": [
        "designesy-mcp"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add le-vai-designesy-org -- uvx designesy-mcp
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "le-vai-designesy-org": {
      "type": "local",
      "command": [
        "uvx",
        "designesy-mcp"
      ],
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add le-vai-designesy-org --command uvx --arg designesy-mcp
```

### Hermes

```yaml
mcp_servers:
  le-vai-designesy-org:
    command: "uvx"
    args: ["designesy-mcp"]
```

### Netclaw

```json
{
  "McpServers": {
    "le-vai-designesy-org": {
      "Transport": "stdio",
      "Command": "uvx",
      "Arguments": [
        "designesy-mcp"
      ]
    }
  }
}
```

### Vellum

```bash
assistant mcp add le-vai-designesy-org -t stdio -c uvx -a designesy-mcp
```

### Other

```json
{
  "mcpServers": {
    "le-vai-designesy-org": {
      "command": "uvx",
      "args": [
        "designesy-mcp"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-09-19 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-17 (score 78, +1)

No change was recorded against any check on this day. Stability & Change Management went from 80 to 83. That category is still filling its 30-day observation window: 24 days of observed history at the previous scan, 25 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-16 (score 77, −3)

- [functional] Stability: pass → 0.80

### 2026-09-15 (score 80, +15)

- [security improvement] Malware scan: unverified → pass

### 2026-09-14 (score 65, −15)

- [security regression] Malware scan: pass → unverified

### 2026-09-13 (score 80, 0)

- [security] Stability: 0.97 → pass

### 2026-09-12 (score 80, +1)

No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-09-10 (score 79, +1)

No change was recorded against any check on this day. Stability & Change Management went from 87 to 90. That category is still filling its 30-day observation window: 26 days of observed history at the previous scan, 27 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (17)

### `designesy_catalog` (~108 tokens)

List the 23 published Designesy packages with versions, URLs, and statuses. Use this to discover what Designesy publishes before fetching a specific contract. When NOT to use: if you already know which package you need, skip this and call designesy_contract directly. Read-only — no side effects. Returns JSON: { package_count, packages[{id, kind, title, version, status, human_url, machine_url}], standing_rules[], machine_exports[] }. No parameters — accepts empty input.

### `designesy_contract` (~211 tokens)

Get the Designesy design-system contract — the canonical tokens, motion, acoustic, takt, cadence, typography, components, and verification rules that define what the Designesy org considers legitimate design. Use this when you need the actual contract values (token names and values, motion timings, accessibility rules) to author, check, or bind a design. When NOT to use: for a pass/fail score of a live site, use designesy_score; for an agent-skill-format export, use designesy_skill_md. Read-only — cached ~24h server-side. Returns the full contract JSON, or a single section when 'section' is provided. Pass section to get one slice (e.g. 'motion' for just the motion tokens) instead of the full contract — saves tokens when you only need one dimension.

Input parameters:

- `section` (string): Optional: filter to a specific contract section (colors, motion, acoustic, typography, takt, cadence, verification, open_tensions, components, interaction).

### `designesy_design_review` (~252 tokens)

Get the Designesy Design Review framework — an 8-dimension rubric (Purpose, Clarity, Context, Inclusion, System coherence, Durability, Delight, Responsibility) plus the agent prompt, output format, and verification checklist for a qualitative design critique. Use this when you want a structured rubric to critique a design holistically, rather than a numeric compliance score. When NOT to use: for a deterministic numeric score, use designesy_score; this tool gives you a rubric, not a number. Read-only — returns the rubric + prompt. The calling agent performs the actual critique (this tool does not evaluate the design for you). Returns JSON: { rubric, dimensions[8], agent_prompt, output_format, verification_checklist }. Pass artifact/purpose/context/rules to get a pre-filled critique prompt; omit all four to get the blank framework.

Input parameters:

- `artifact` (string): URL or description of the artifact to review.
- `context` (string): Audience, device, environment, and constraints.
- `purpose` (string): What the design is trying to make possible.
- `rules` (string): Governing rules or contract version (default: designesy design system v0.3.0).

### `designesy_skill_md` (~142 tokens)

Get the Designesy SKILL.md — the agent-skill-format export of the design-system contract, written as behavioral rules an AI coding agent can drop into .agents/skills/ or a system prompt. Use this when you want the contract in a form that steers how an agent *builds* UI (tokens, anti-patterns, behavioral rules, verification). When NOT to use: for the raw contract JSON, use designesy_contract; for scoring, use designesy_score. Read-only — no side effects. Returns markdown text (SKILL.md format) — drop into .agents/skills/ or paste into a system prompt. No parameters.

### `designesy_agent_json` (~142 tokens)

Get the Designesy agent discovery document (/.well-known/agent.json) — the org identity, authority, ingest protocol, package index, machine-export list, permission policy, and citation templates. Use this when you are integrating with or enumerating Designesy as a machine agent and need the canonical discovery/manifest endpoint rather than one specific contract. When NOT to use: for the package list, use designesy_catalog (lighter); for the contract, use designesy_contract. Read-only — no side effects. Returns the /.well-known/agent.json object: { identity, authority, ingest_protocol, package_index, permission_policy, citation_templates }. No parameters.

### `designesy_llms_txt` (~110 tokens)

Get the Designesy /llms.txt — a short agent-facing brief with the canonical reference, topic index, ingest steps, package list, and contact. Use this first when you don't know what Designesy is — it's the cheapest orientation path before pulling heavier artifacts. When NOT to use: for the full expanded brief, use designesy_llms_full_txt; for the contract itself, use designesy_contract. Read-only — no side effects. Returns text/plain (~500 tokens). No parameters.

### `designesy_llms_full_txt` (~122 tokens)

Get the Designesy /llms-full.txt — the complete agent-facing brief: ingest protocol, discovery endpoints, every package, standing rules, anti-patterns, and a paste-ready agent prompt. Use this for comprehensive onboarding to the Designesy ecosystem when the short /llms.txt is not enough. When NOT to use: for a quick orientation, use designesy_llms_txt first (~500 tokens vs ~3000). Read-only — no side effects. Returns text/plain (~3000 tokens, includes a paste-ready agent prompt). No parameters.

### `designesy_score` (~299 tokens)

Score a live URL against the Designesy design contract — a deterministic 42-check verification engine that returns a numeric score, letter grade (A–F), and per-check breakdown. Use this to audit whether a website or AI-generated UI complies with a real design contract (tokens, motion, accessibility, cadence, takt, typography, copywriting). When NOT to use: for token-file validation only, use designesy_tokens_score; for a Lottie file, use designesy_motion_score; for a qualitative critique, use designesy_design_review. Executable — fetches the URL server-side, extracts CSS, runs 42 checks. Results cached ~24h server-side per URL. Checks needing a live browser (Core Web Vitals, sound toggle, overflow) return MANUAL, not FAIL — run the full audit (/api/score/audit) to resolve them. Checks that are not applicable to the site (no tokens, no buttons, no DESIGN.md) return SKIP (N/A). Returns JSON: { url, score (0–100), grade (A–F), pass_count, fail_count, checks[{id, name, status, weight, category}] }. Pass format='canonical' for review-findings.json schema, 'review' for markdown, or 'google' for design.md-compatible output.

Input parameters:

- `url` (string): URL to score. Defaults to https://www.designesy.org/ if not provided.

### `designesy_tokens_score` (~330 tokens)

Validate a design token file against the W3C Design Tokens Community Group (DTCG) 2025.10 Final Community Group Report (the spec's first stable version, published Oct 28 2025 — Candidate Recommendation, considered stable). Returns 10 conformance checks (t01-t10) with PASS/FAIL/WARN. Use this to verify a tokens.json (or any DTCG token export) is structurally correct — $type/$value/$description present, structured colors (colorSpace + components rather than bare hex), a valid $schema pointer to designtokens.org, and correct dimension units. With 84% of teams now using design tokens (zeroheight Design Systems Report 2025, up from 56% in 2024) and the spec finally stable, every adopting team needs a validator. When NOT to use: for scoring a whole live site (not just its token file), use designesy_score. Executable — fetches the URL or parses the raw JSON you provide, runs 10 checks server-side. No browser needed. Returns JSON: { checks[{id (t01–t10), name, status (PASS/FAIL/WARN), detail}], valid, score }. Pass url to fetch a remote token file, or dtcg_file to validate an inline JSON string. Provide exactly one.

Input parameters:

- `dtcg_file` (string): Raw DTCG token JSON string to validate (alternative to url).
- `url` (string): URL to a DTCG token file (JSON). The tool fetches and validates it.

### `designesy_a11y_score` (~300 tokens)

Get the Designesy WCAG 2.2 AA accessibility verification framework: 11 conformance checks (a01-a11) plus a ready-to-run Playwright + axe-core 4.13.0 script template targeting your URL. Use this to audit a site for accessibility violations. When NOT to use: for a full design-contract score (not just a11y), use designesy_score. Does NOT run the scan — axe-core needs a real browser DOM. Returns the 11 checks + a Playwright script you execute locally (npm i -D @axe-core/playwright). The score comes from your local run, not from this tool. Returns JSON: { checks[{id (a01–a11), name, status: 'PENDING_EXECUTION'}], playwright_script, install_command, run_command }. Pass config (JSON string) to customize axe.configure() — e.g. branding overrides, rule disables. Omit for standard WCAG 2.2 AA.

Input parameters:

- `config` (string): Brand customization JSON for axe.configure() - branding, checks, rules, disableOtherRules.
- `ruleset` (string): Ruleset tag (default: wcag22aa). Options: wcag2a, wcag2aa, wcag21aa, wcag22aa, best-practice.
- `url` (string, required): URL to scan for accessibility. The returned script template will target this URL.

### `designesy_motion_score` (~308 tokens)

Validate a Lottie animation file against the Lottie spec v1.0.1 and the Designesy §16 Ten Non-Negotiable Motion Standards, returning 10 checks (m01-m10) with PASS/FAIL/WARN. The DTCG 2025.10 spec leaves motion tokens as a second-class citizen — there is no standard for motion token structure, reduced-motion markers, or animation accessibility. Designesy's motion validator fills this gap: it checks required fields (v, fr, ip, op, w, h, layers), $version, a markers array for reduced-motion compliance, and no deprecated version. Use this to verify a motion/animation asset is well-formed AND accessible — the only validator that checks both. When NOT to use: for full-site motion scoring (not a single Lottie file), use designesy_score. Executable — fetches the URL or parses the raw Lottie JSON, runs 10 checks server-side. No browser needed. Returns JSON: { checks[{id (m01–m10), name, status (PASS/FAIL/WARN), detail}], valid, score }. Pass url to fetch a remote Lottie file, or lottie_file to validate an inline JSON string. Provide exactly one.

Input parameters:

- `lottie_file` (string): Raw Lottie JSON string to validate (alternative to url).
- `url` (string): URL to a Lottie JSON file. The tool fetches and validates it.

### `designesy_drift_score` (~262 tokens)

Score a live URL for AI-generated UI drift — 12 checks detect the four documented 2026 drift failure modes: token fabrication (var() to undeclared custom properties), within-session drift (spacing/color/radius value variance), between-session amnesia (inconsistent font stacks, shadows, transitions), and silent breaking changes (z-index chaos, dangling alias chains). Use this when you need to verify whether a site (especially an AI-generated one) is drifting off its own declared token system. When NOT to use: for a full 42-check design-contract score, use designesy_score; for token-file format validation, use designesy_tokens_score. Executable — fetches the URL server-side, extracts all CSS (inline + linked stylesheets), parses :root custom properties and var() references, runs 12 drift checks. No browser needed. Returns JSON: { ok, url, score (0-100), grade (A-F), pass, warn, fail, total, tokensExtracted, checks[{id, item, category, status, detail}] }. Results cached ~24h server-side per URL.

Input parameters:

- `url` (string): URL to scan for drift. Defaults to https://www.designesy.org/ if not provided.

### `designesy_readiness_score` (~242 tokens)

Score a URL for design-system AI readiness — the 6th maturity axis (zeroheight 2026). 10 checks probe the target origin for machine-readable artifacts: DTCG token files, llms.txt, agent.json, MCP endpoint (tools/list), DESIGN.md, token $description, component schemas, sitemap.xml, robots.txt, and Open Graph/Twitter meta. Use this to verify whether a design system is the default context AI tools build from, or whether AI is silently working around it. When NOT to use: for full design-contract scoring, use designesy_score; for AI-drift detection, use designesy_drift_score. Executable — fetches the URL and probes the origin via HEAD/GET for each artifact. No browser needed. Returns JSON: { ok, url, score (0-100), grade (A-F), pass, warn, fail, total, checks[{id, item, category, status, detail}] }. Results cached ~24h server-side per URL.

Input parameters:

- `url` (string): URL to score for AI readiness. Defaults to https://www.designesy.org/ if not provided.

### `designesy_guardrails` (~321 tokens)

Generate a frozen build-contract bundle for AI coding agents from any design system URL — the product layer. Ingests a site, extracts its :root tokens, and emits 6 outputs: (1) DTCG-format token file, (2) Stylelint config generated from token values, (3) AGENTS.md-format rules with token allowlist, (4) component contract with allowed prop patterns, (5) anti-pattern documentation, (6) DESIGN.md file (Google open spec, google-labs-code/design.md) — YAML front matter + markdown body, the de-facto AI-readable design-context standard. Use this when you need to turn a design system into the file AI agents read and the lint that enforces it. When NOT to use: for design-contract scoring, use designesy_score; for token-file validation, use designesy_tokens_score; for drift detection, use designesy_drift_score. Executable — fetches the URL, extracts CSS + :root custom properties, generates the bundle. No browser needed. Returns JSON: { ok, url, score (0-100, emission completeness), grade, pass, warn, fail, total, tokensExtracted, bundle: { tokens, lintConfig, agentRules, componentContract, antiPatterns, designMd }, checks[{id, item, category, status, detail}] }. Results cached ~24h server-side per URL.

Input parameters:

- `url` (string): URL to generate guardrails for. Defaults to https://www.designesy.org/ if not provided.

### `designesy_monitor_score` (~389 tokens)

Score a URL for continuous design-drift governance — the temporal layer over the drift radar. Re-runs the 12 drift checks (d01-d12) on the URL and computes 10 monitor checks (m01-m10): schedule registered, last run fresh, drift delta vs baseline, trend slope (3-run trajectory), new violations since last run, resolved since last run (the healing signal), score degradation threshold, token-set mutation, contract version drift, and alert delivered. When alerts fire and an email address is provided, sends an HTML drift-alert email via Resend (requires RESEND_API_KEY env var). Pass a history array of prior snapshots to compute deltas; omit it for a first-run baseline. Use this to watch a design system over time — 'weekly audits at cents per report' (Into Design Systems 2026). When NOT to use: for a single point-in-time drift check, use designesy_drift_score; for design-contract scoring, use designesy_score. Executable — fetches the URL, extracts CSS + :root tokens, runs checks, computes deltas. No browser needed. Returns JSON: { ok, url, score (0-100, governance health), grade (A-F), pass, warn, fail, total, currentSnapshot, baseline, previous, driftChecks, monitorChecks, alerts, emailAlert }. Results cached ~24h server-side per URL.

Input parameters:

- `email` (string): Email address to receive drift alerts. When alerts fire AND this is provided AND RESEND_API_KEY is set, an HTML alert email is sent. Optional — without it, alerts surface in-UI only.
- `history` (array): Prior snapshots for delta computation. Omit for a first-run baseline.
- `url` (string): URL to monitor for drift. Defaults to https://www.designesy.org/ if not provided.

### `designesy_compare` (~327 tokens)

Diff two design systems from live URLs — the only URL-scoped design-token diff engine. Fetches both URLs in parallel, extracts their :root custom properties, and produces a structured diff across 8 dimensions: tokens added (in A not B), removed (in B not A), renamed (heuristic Levenshtein ≤ 2), value-changed (same name, different value), scale-stop-changed (spacing/radius/color scale steps), contrast-drift-per-pair (WCAG contrast ratio change for shared color tokens), structure-delta (token count + category distribution), and score-delta (runs /score on both URLs and diffs). Use this to answer 'what actually changed between two design systems' or 'how does our design system differ from a reference'. When NOT to use: for single-site drift detection, use designesy_drift_score; for continuous monitoring, use designesy_monitor_score. Executable — fetches both URLs, extracts CSS + tokens, computes diff. No browser needed. Returns JSON: { ok, urlA, urlB, score (0-100, diff completeness), grade, pass, warn, fail, total, tokensA, tokensB, added[], removed[], renamed[], valueChanged[], scaleDiff, structureDelta, contrastDrift[], scoreDelta, checks[] }. Results cached ~24h server-side per URL pair.

Input parameters:

- `urlA` (string, required): First URL to compare (e.g. your design system).
- `urlB` (string, required): Second URL to compare (e.g. a reference or competitor).

### `designesy_report` (~305 tokens)

Generate a unified design-intelligence report for a single URL — the synthesis capstone of the Designesy dynasty. Fires /score (42-check audit), /drift (12-check drift radar), and /readiness (10-check AI readiness) in parallel, then computes a weighted composite: score × 0.5 + drift × 0.3 + readiness × 0.2. One input, one output, one composite grade. Use this when you need a single holistic assessment instead of three separate scans, or when sharing a design-intelligence verdict (the report is the most shareable surface). When NOT to use: for just the audit score, use designesy_score; for just drift, use designesy_drift_score; for just AI readiness, use designesy_readiness_score. Executable — fires 3 internal APIs in parallel, each fetches the target URL. No browser needed. Returns JSON: { ok, url, compositeScore (0-100), compositeGrade (A-F), score { sub-result }, drift { sub-result }, readiness { sub-result }, totalChecks, totalPass, totalWarn, totalFail, totalSkip, checks[] (all checks across all engines, tagged with engine), synthesis[] (8 synthesis checks verifying the report ran correctly), appUrl (standalone interactive dashboard URL) }. Results cached ~24h server-side per URL.

Input parameters:

- `url` (string, required): Public URL to generate a design-intelligence report for.

## Diagnostics

Captured diagnostic sections: Provenance, Install scripts, Dependencies. The full working is on the page: https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp#diagnostics

## Score history

- 2026-09-20: 79
- 2026-09-19: 79
- 2026-09-18: 78
- 2026-09-17: 78
- 2026-09-16: 77
- 2026-09-15: 80
- 2026-09-14: 65
- 2026-09-13: 80
- 2026-09-12: 80
- 2026-09-11: 79
- 2026-09-10: 79
- 2026-09-09: 78
- 2026-09-08: 80
- 2026-09-07: 80
- 2026-09-06: 80
- 2026-09-05: 80
- 2026-09-04: 80
- 2026-09-03: 79
- 2026-09-02: 79
- 2026-09-01: 78
- 2026-08-31: 78
- 2026-08-30: 62
- 2026-08-29: 80
- 2026-08-28: 80
- 2026-08-27: 79
- 2026-08-26: 79
- 2026-08-25: 77
- 2026-08-24: 61
- 2026-08-23: 76
- 2026-08-22: 75

## Common questions

### What is the Designesy MCP server?

Designesy is an MCP server listed in the public MCP registry as io.github.LE-VAI/designesy-org. Score any URL against a real design contract, 42 checks, A-F grade, token + motion validation. This page covers its PyPI package (designesy-mcp).

### Is the Designesy MCP server safe to use?

Designesy scores 79 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Designesy MCP server expose?

Designesy exposes 17 tools: designesy_catalog, designesy_contract, designesy_design_review, designesy_skill_md, designesy_agent_json, and 12 more. Their descriptions and schemas cost roughly 4,170 tokens of context every time the server is loaded.

### Is the Designesy MCP server still maintained?

Designesy is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- PyPI project: https://pypi.org/project/designesy-mcp/
- Socket report: https://socket.dev/pypi/package/designesy-mcp
- Repository: https://github.com/LE-VAI/designesy-org
- Website: https://www.designesy.org/
- Changelog RSS feed: https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp.json
- HTML version of this page: https://verifymcp.io/servers/le-vai-designesy-org/designesy-mcp