ds-canon

by jtrainer357

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing vs. retrieving specific entities, finding usages, checking deprecations, conventions, and code drift. The overlap between whats_deprecated and filtered token/component lists is minimal because the former is specifically about deprecated items and their migration targets.
Naming Consistency4/5
Most tools follow a verb_noun pattern (list_tokens, get_component, find_usages, check_token_drift), but whats_deprecated breaks the pattern with a question-style name. Overall the naming is predictable and readable, with one minor deviation.
Tool Count5/5
8 tools is well-scoped for a design system canonical server. Each tool addresses a distinct need (querying, detail lookup, dependency analysis, conventions, drift checking) and none feel redundant or unnecessary.
Completeness5/5
The tool surface comprehensively covers the design system domain: token and component listing/detail, deprecation info, reverse dependencies, conventions, and code drift detection. For a read-only reference server, the coverage is complete and leaves no obvious dead ends.
Average 3.8/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 14 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It states that the tool returns conventions and optionally filters by topic, which is useful. However, it does not disclose default behavior (e.g., returns all topics when no filter is provided) or any other behavioral details such as output format or handling of empty results. The presence of an output schema partially compensates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with a plain-language question and then a crisp summary of the return value and optional filter. Every word earns its place, with no redundant or ambiguous filler.
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 simple tool with one enum parameter and an output schema, the description is reasonably complete: it communicates the core purpose, the topics covered, and the optional filtering behavior. It lacks sibling differentiation and usage guidance, but those gaps are partially acceptable given the tool's low complexity and the output schema's presence.
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?
The single 'topic' parameter is fully enumerated in the schema with an enum, and the description lists the same five topics. The phrase 'optionally filtered to one topic' clarifies that the parameter is optional and controls filtering, adding modest meaning beyond the schema. It does not explain the semantics of each topic choice, but those are largely self-explanatory.
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?
The description clearly states the tool 'returns naming, spacing, color, accessibility, or deprecation conventions' with an optional topic filter. The verb 'Returns' plus the resource 'conventions' makes the purpose specific, but it does not explicitly distinguish itself from the sibling tool 'whats_deprecated', which may overlap on the deprecation topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context about what the tool does and the optional filter, but it provides no explicit guidance on when to use this tool versus alternatives like 'whats_deprecated' or 'list_tokens'. There is no when-to-use or when-not-to-use framing, leaving the agent to infer usage from the topic list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses that the tool returns full token detail and consumers, and indicates exact-name matching. However, it does not explain error behavior, permissions, or other potential side effects, which would be useful for a get operation.
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?
The description is concise and front-loaded with a purpose question followed by a direct statement. It earns its place without being wordy, though the question could be integrated into a single declarative sentence.
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?
Given its simplicity (one parameter, output schema present), the description covers the essential information: what is returned, the exact-name constraint, and the resource focus. It is complete enough for an agent to select and invoke the tool correctly, though it does not mention edge-case behavior.
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?
The schema has 0% description coverage, so the description must compensate. Saying 'by exact name' adds context that the 'name' parameter is an exact match identifier, but it omits details like case sensitivity or token format. This is partial compensation for the schema gap.
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?
The description clearly states the tool returns full token detail plus consuming components by exact name. This specific verb and resource scope distinguish it from siblings like list_tokens (which lists tokens) and list_components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'by exact name' implies the tool is intended for when the exact token name is known, not for searching. However, it does not explicitly mention alternatives or when not to use this tool, leaving the guidance implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It states the scan targets (hex colors, px values) and the suggestion of matching or nearest token. It does not discuss edge cases such as no matching token, language support, or that the operation is read-only, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It avoids redundancy and front-loads the core question.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a clear purpose and an output schema, but the description omits the meaning of the 'lang' parameter and lacks details about failure/fallback behavior. For a tool with only 2 parameters and no annotations, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 'snippet' implicitly, but 'lang' is entirely unexplained. The schema provides no descriptions, and the enum values (css, jsx, text) lack context for why lang matters, which is a significant gap.
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?
The description uses a specific verb ('Scans') and identifies the resource ('a snippet') and the action ('suggests the matching or nearest token'). It clearly differentiates from sibling tools like list_tokens or get_token by focusing on drift detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The question format 'Does this code drift from the token system?' establishes a clear use case. However, it doesn't explicitly mention when not to use this tool or point to alternatives like list_tokens, though the sibling context makes the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does disclose the case-insensitive substring matching and optional filtering behavior. However, it does not state default behavior (e.g., returns all tokens when no filters are provided), result ordering, or any performance caveats. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with a clear question and concise statement. Every word earns its place, and it avoids unnecessary detail.
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?
With an output schema provided, return values are already covered. The description covers the core behavior and all filter options. It lacks an explicit statement about the no-filter case, but that is easily inferred. The overall simplicity of the tool makes this description sufficiently complete.
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 description coverage is 0%, so the description must compensate. It names all three parameters (group, status, and implicitly query via 'substring match') and adds specific semantics for query (case-insensitive match on name and description). Group and status receive no additional meaning beyond their names, though status has an enum in the schema.
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?
The description clearly states 'Lists design tokens' with optional filters, providing a specific verb and resource. It distinguishes from sibling tools like get_token (single token) and list_components (components) by focusing on the token collection with filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for browsing tokens and mentions the available filters, but it does not explicitly state when to use this tool versus alternatives like get_token or whats_deprecated. It provides no exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output contents and the exact-name requirement, but does not reveal behavior on missing components, error handling, or authorization needs, which are relevant for a lookup tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with a question, and lists the return contents efficiently. Every word adds value without redundancy.
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?
Given the simplicity of the tool (one parameter), the description provides adequate context about what is returned and the need for exact name. The presence of an output schema covers return shape, but edge-case behavior (e.g., not found) is not described, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'by exact name' without elaborating on the 'name' parameter's format, case sensitivity, or examples. The description does not sufficiently compensate for the lack of schema-level parameter documentation.
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?
The description clearly states the tool returns full component detail including props, variants, tokens, and anti-pattern guidance. This distinguishes it from siblings like get_token or list_components by focusing on the component itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for looking up a component by exact name, providing clear context. However, it does not explicitly mention alternative tools or when not to use it, such as when needing a list of components or token-specific information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool lists summaries and supports filtering, which is useful. But it omits details like default behavior when no filters are provided, pagination, or any side-effect guarantees. A simple list tool likely needs no such warnings, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two punchy sentences: a front-loaded question that sets context, followed by a compact declaration of the tool's output and optional filtering. Every word earns its place with no redundancy.
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?
Given that an output schema exists and the tool has only two optional parameters, the description covers the core functionality well. It mentions the returned data points (names, status, tags, summaries) and the filtering capability. It lacks some nuance like how filters interact, but overall is complete for a straightforward list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only says 'optionally filtered by status or tag.' It adds the meaning that these parameters are filters, but it does not explain the tag parameter's format or semantics, nor what values are allowed beyond the enum visible in the schema. The description partially compensates but leaves gaps.
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?
The description opens with 'What components exist?' and then states 'Lists component names, status, tags, and summaries' – a specific verb and resource. It clearly distinguishes from siblings like get_component (single retrieval) and list_tokens (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'optionally filtered by status or tag' provides clear context for when to use the tool (exploration/discovery). However, it does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the output contents (deprecated items, migration targets, dependency counts) but does not mention potential performance implications of scanning 'every' deprecated item, what 'active entities' means, or any limitations. It provides basic transparency but lacks deeper behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, just two short sentences. The rhetorical question front-loads the purpose, and the subsequent sentence packs all key information without wasted words.
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?
Given the tool's simplicity (0 parameters, output schema present), the description is sufficient for an agent to understand what the tool returns and when it might be relevant. It doesn't explain how its output relates to sibling tools like check_token_drift, but that is a minor gap given the clear purpose and existing structured context.
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?
The tool has zero parameters, so the schema covers everything. The description adds no parameter semantics, but with 0 params the baseline is 4 per the rubric. There is nothing to compensate for.
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?
The description clearly states what it does: 'Lists every deprecated token and component, its migration target, and how many active entities still depend on it.' This specifically distinguishes it from sibling tools like list_tokens or list_components, which list all items, not just deprecated ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The opening question 'What should I stop using?' implies a use case, but the description does not explicitly contrast with alternatives (e.g., use this instead of list_tokens when you only care about deprecated items). No exclusions or when-not-to-use guidance is provided, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add key behavior: the lookup is by exact name, and it targets reverse dependencies. However, it omits other behavioral aspects such as whether the search is case-sensitive, whether it scans all files/projects, or if it includes transitive dependencies. The existence of an output schema covers return format, so this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It opens with a meaningful framing question and immediately follows with the technical definition. Every word serves a purpose, with no redundancy or filler.
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 simple one-parameter tool with an output schema, the description covers the purpose, the key matching constraint, and parameter semantics. It could add more explicit guidance on usage context (e.g., 'before changing a token or component'), but the question at the start already conveys this. Overall, it is sufficiently complete given the tool's simplicity.
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?
The input schema has only 'entity' with no description and no schema description coverage. The description adds crucial meaning by stating the lookup is 'for a token or component' and 'by exact name', thus clarifying that 'entity' is the exact name of a token or component. This significantly compensates for the schema's lack of documentation, though it doesn't address edge cases like not found behavior, so not a 5.
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?
The description clearly frames the tool's purpose with the question 'What breaks if I change this?' and then defines it as a 'Reverse-dependency lookup for a token or component, by exact name.' This specifies the verb (lookup) and resource (reverse-dependencies), effectively distinguishing it from siblings like get_token/get_component which fetch the entity itself, and list_* tools that enumerate all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to assess the impact of changing a token or component, by finding reverse dependencies. The phrase 'by exact name' is an explicit usage condition. However, it does not name specific alternatives or explicitly state when not to use it, but the context is clear enough given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ds-canon MCP server](https://glama.ai/mcp/servers/jtrainer357/ds-canon/badges/card.svg)](https://glama.ai/mcp/servers/jtrainer357/ds-canon)

Score Badge

Copy to your README.md:

[![ds-canon MCP server](https://glama.ai/mcp/servers/jtrainer357/ds-canon/badges/score.svg)](https://glama.ai/mcp/servers/jtrainer357/ds-canon)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jtrainer357/ds-canon'

If you have feedback or need assistance with the MCP directory API, please join our Discord server