Designesy

Monitor drift over time

designesy_monitor_score

Read-onlyIdempotent

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): history supplied, 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. Alerts come back in the result as alerts[]. No email is sent: email delivery was retired, so m10 is SKIP on every run and is not scored, and the email argument is deprecated and ignored. Pass a history array of prior snapshots (each call's currentSnapshot) to compute deltas; omit it for a first-run baseline. History is checked for shape and bounds (at most 1000 runs, a request of at most 512 KB). 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; SKIP is not scored), grade (A-F), pass, warn, fail, total, currentSnapshot, baseline, previous, driftChecks, monitorChecks, alerts }. Results are cached ~24h per URL and history: a repeat call with the same URL and history returns the cached run, with m02 measured again.

Input Schema

Name	Required	Description
`url`	No	URL to monitor for drift. Defaults to https://www.designesy.org/ if not provided.
`email`	No	Deprecated and ignored: email delivery was retired, so no email is sent and the address is not forwarded. Alerts come back in the result as alerts[].
`history`	No	Prior snapshots for delta computation (currentSnapshot from earlier calls). Omit for a first-run baseline.

Schema Changelog

Changes observed during successful MCP inspections.

Changed18 schema fields changedOct 24, 2026
- changedInput schema / properties / email / description
```
Previous value: -"Email address to receive drift alerts. When alerts fire AND this is provided AND the server has email alerts switched on (MONITOR_EMAIL_ENABLED=true, RESEND_API_KEY set), an HTML alert email is sent. Optional: without it, alerts surface in-UI only."New value: +"Deprecated and ignored: email delivery was retired, so no email is sent and the address is not forwarded. Alerts come back in the result as alerts[]."
```
- changedInput schema / properties / history / description
```
Previous value: -"Prior snapshots for delta computation. Omit for a first-run baseline."New value: +"Prior snapshots for delta computation (currentSnapshot from earlier calls). Omit for a first-run baseline."
```
- addedInput schema / properties / history / items / properties / checks / items / properties / category / maxLength
```
Added value: +64
```
- addedInput schema / properties / history / items / properties / checks / items / properties / detail / maxLength
```
Added value: +4096
```
- addedInput schema / properties / history / items / properties / checks / items / properties / id / pattern
```
Added value: +"^d(0[1-9]|1[0-2])$"
```
- addedInput schema / properties / history / items / properties / checks / items / properties / item / maxLength
```
Added value: +200
```
- changedInput schema / properties / history / items / properties / checks / items / properties / status / enum
```
Previous value: -[
-  "PASS",
-  "FAIL",
-  "WARN"
-]New value: +[
+  "PASS",
+  "FAIL",
+  "WARN",
+  "SKIP"
+]
```
- changedInput schema / properties / history / items / properties / checks / items / required
```
Previous value: -[
-  "id",
-  "item",
-  "category",
-  "status",
-  "detail"
-]New value: +[
+  "id",
+  "status"
+]
```
- addedInput schema / properties / history / items / properties / checks / maxItems
```
Added value: +12
```
- addedInput schema / properties / history / items / properties / grade / enum
```
Added value: +[
+  "A",
+  "B",
+  "C",
+  "D",
+  "F"
+]
```
- addedInput schema / properties / history / items / properties / score / maximum
```
Added value: +100
```
- addedInput schema / properties / history / items / properties / score / minimum
```
Added value: +0
```
- addedInput schema / properties / history / items / properties / timestamp / maxLength
```
Added value: +64
```
- addedInput schema / properties / history / items / properties / tokensExtracted / maximum
```
Added value: +1000000
```
- addedInput schema / properties / history / items / properties / tokensExtracted / minimum
```
Added value: +0
```
- changedInput schema / properties / history / items / properties / tokensExtracted / type
```
Previous value: -"number"New value: +"integer"
```
- changedInput schema / properties / history / items / required
```
Previous value: -[
-  "timestamp",
-  "score",
-  "grade",
-  "tokensExtracted",
-  "checks"
-]New value: +[
+  "score",
+  "tokensExtracted",
+  "checks"
+]
```
- addedInput schema / properties / history / maxItems
```
Added value: +1000
```

Changed1 schema field changedOct 24, 2026

changedInput schema / properties / email / description

Previous value: -"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."New value: +"Email address to receive drift alerts. When alerts fire AND this is provided AND the server has email alerts switched on (MONITOR_EMAIL_ENABLED=true, RESEND_API_KEY set), an HTML alert email is sent. Optional: without it, alerts surface in-UI only."

Changed1 schema field changedSep 28, 2026

changedInput schema / properties / email / description

Previous value: -"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."New value: +"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."

Changed1 schema field changedAug 3, 2026

addedInput schema / properties / email

Added value: +{
+  "description": "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.",
+  "type": "string"
+}

Changed4 schema fields changedAug 3, 2026
- changedInput schema / $schema
```
Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
```
- removedInput schema / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / history / items / additionalProperties
```
Removed value: -false
```
- removedInput schema / properties / history / items / properties / checks / items / additionalProperties
```
Removed value: -false
```
AddedAug 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the readOnly/openWorld/idempotent annotations: it discloses that no email is sent (m10 is SKIP and not scored, email argument deprecated and ignored), that the call is executable and fetches the URL with no browser needed, that history is validated for shape and bounds (1000 runs, 512 KB), and that results are cached ~24h per URL+history with m02 re-measured. These are exactly the traits annotations cannot express.

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 core history mechanic are front-loaded, and the return-shape summary is compact. The mid-section enumeration of all ten monitor checks (m01–m10) is dense and partly padding, but it does tell the agent what the governance score measures, so it mostly earns its place.

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

Completeness5/5

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

For a no-output-schema, open-world, network-fetching tool, the description covers execution model, history contract, caching/idempotency caveat, the full return JSON shape and the alert-in-result behavior. An agent has everything needed to call it correctly and interpret the response.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: history should contain prior calls' currentSnapshot objects for delta computation, and omitting it produces a baseline run. It also restates the email deprecation alongside the schema, reinforcing rather than adding. Useful marginal value, though the bounds numbers are largely mirrored in the schema's maxItems.

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

Purpose5/5

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

States a specific verb and resource — scoring a URL for continuous design-drift governance over time — and frames it as 'the temporal layer over the drift radar'. It explicitly names the siblings it supersedes in different cases (designesy_drift_score for point-in-time, designesy_score for contract scoring), so the agent can separate it from 16 siblings without opening a schema.

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 explicit when-to-use ('watch a design system over time'), explicit when-NOT-to-use with named alternative tools for each case, and operational guidance on the history argument (pass prior currentSnapshot values for deltas, omit for a first-run baseline). Nothing about selection is left to inference.

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

All Designesy tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Monitor drift over time

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources