Design SystemSAFE
Overview
From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.
This project includes an MCP (Model Context Protocol) server that provides information about component props and design tokens.
MCP Server Features
The MCP server offers two main tools:
getComponentProps: Retrieves information about component propertiesgetTokens: Retrieves design token information from token files
Debugging the MCP Server
To debug the MCP server:
- Run the in-memory debug script:
$ deno task debug-mcp
This script:
- Creates an in-memory client-server connection
- Makes sample calls to retrieve component props and tokens
- Displays the results in the console
You can modify the debug script to test different components or specific token requests.
Design Token Generation
Design tokens are stored as JSON files in the src/design-system/tokens directory:
color.json: Color palette and theme colorstypography.json: Font families, sizes, weightsspacing.json: Spacing scaleradius.json: Border radius values
Token Generation Process
Tokens are processed using Style Dictionary with the following workflow:
- Define token values in JSON files in the
tokensdirectory - Style Dictionary processes these tokens according to the configuration in
src/design-system/style-dictionary/config.json - Output formats include:
- CSS variables (tokens.css)
- JavaScript module (tokens.js)
- TypeScript declarations (tokens.d.ts)
To generate tokens:
$ deno task build-tokens
The generated files are placed in the src/design-system/style-dictionary/dist directory and can be imported into your components.
87e060715823OBSERVED · 2026-10-09Exposed tools (2)
2 read · 0 write · 0 destructive.
| Tool | Risk | Description |
|---|---|---|
getComponentProps | read | |
getTokens | read |
Trust audit
SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | PASS |
| L1 | Static analysis of the code | PASS |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (1)
Gates applied: no_behavioural_pass, no_license.
87e060715823full audit observations/trust-audit/mcp-server/yajihum__design-system.json · Report an issue / request a re-scanAudit history
Every audit this server has had. A grade with a past is a grade somebody is still checking.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-09 | 87e060715823 | SAFE | B | 89 | first audit |
Questions
What tools does Design System expose?
2 in total: 2 read-only, 0 that write, and 0 that can delete or overwrite. Every one is listed on this page with its risk.
Is Design System safe to connect to an agent?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean server reads B.
What credentials does Design System need?
No credential environment variables were found in its source, so it appears to need none.
How does Design System run?
It speaks stdio, so it runs as a local process your client starts.
How current is this page?
The grade is for one exact copy of the source (87e060715823), read on 2026-10-09. The repository is watched and re-audited when it changes.