Skip to main content
Glama

Axcess — Design Accessibility Evaluation

by io.github.sicxz

Evaluate Typography Accessibility

evaluate_typography
Read-onlyIdempotent

Evaluates typography elements against a principled accessibility rubric.

COST: $0.05 USDC via x402 on Base-compatible EVM network per call.

Goes beyond what axe/Lighthouse/WAVE can check — evaluates design judgment, not just numeric compliance. Catches issues like:

  • Contrast that passes WCAG 4.5:1 but fails visually due to thin font weight

  • Body text that meets minimum size requirements but is still too small for comfortable reading

  • Line heights that technically comply but impede readability for dyslexic users

  • Extended all-caps or italic text that passes all AA criteria but impairs reading

  • Text on gradient/image backgrounds where scanner sampling is unreliable

  • Heading sizes that are technically correct but visually indistinct from body

Args:

  • elements: Array of 1–50 typography element objects with font/color properties

  • screen_name: Optional label for the evaluation report

Each element requires: element_type, font_size, font_weight, line_height, color_hex, background_color_hex.

Returns: Structured report with:

  • Per-element scores (0–100)

  • Specific issues with severity (critical/major/minor)

  • WCAG references and what automated tools miss

  • Concrete fix recommendations

  • Overall score and verdict (pass/needs_work/fail)

  • Top issues sorted by severity

Example use: Extract text layer properties from Figma using get_design_context, pass the typography properties to this tool for evaluation before shipping.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
elementsYesArray of typography elements to evaluate
screen_nameNoName of the screen or component being evaluated

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds valuable behavioral context: a per-call cost of $0.05 USDC on a Base-compatible EVM network and the tool's emphasis on subjective design evaluation rather than pure numeric checks. This goes beyond the annotations.

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 well-organized with a clear first sentence, cost notification, bulleted capabilities, parameter list, return format, and example. It is somewhat lengthy but every section serves a purpose; the bullet list of issues clarifies the tool's value without being redundant. A small deduction for verbosity.

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?

Given there is no output schema, the description explicitly and thoroughly details the return structure (per-element scores, issues, WCAG references, fix recommendations, overall verdict). It also covers cost, a usage example, and parameter requirements. This is complete for a tool of this 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 description coverage is 100%, so the schema already documents all parameters. The description's Args section repeats the schema's information (e.g., array size, required fields) without adding new semantics. Per the rubric, a baseline of 3 is appropriate when the schema carries the full burden.

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 'Evaluates typography elements against a principled accessibility rubric' – a specific verb and resource that clearly defines its scope. It distinguishes itself from sibling tools by focusing on typography-specific design judgment and explicitly contrasts with generic automated checkers (axe/Lighthouse/WAVE), making its unique role clear.

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 provides clear context for when to use the tool: when design judgment beyond numeric compliance is needed, with a concrete example workflow via get_design_context. However, it does not explicitly state when not to use it or directly contrast with the sibling evaluate_accessibility tool, 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.

All Axcess — Design Accessibility Evaluation toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

The three tools have clearly distinct purposes with no overlap. evaluate_accessibility focuses on UI element accessibility, evaluate_typography handles typography-specific evaluation, and list_capabilities provides metadata about available tools. An agent can easily distinguish between them based on their specialized domains.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case formatting: evaluate_accessibility, evaluate_typography, and list_capabilities. This predictable naming convention makes the tool set easy to navigate and understand at a glance.

Tool Count3/5

With only three tools, the set feels somewhat thin for a server focused on 'Design Accessibility Evaluation.' While the two evaluation tools cover distinct aspects, the domain suggests potential gaps in areas like color contrast evaluation or mobile-specific accessibility checks that aren't addressed.

Completeness3/5

The server covers two specific evaluation domains (general UI accessibility and typography) with dedicated tools, but lacks broader coverage expected for design accessibility. Missing are tools for color contrast evaluation, mobile/touch-specific checks beyond touch targets, and integration with design tools beyond the mentioned Figma example. The surface is functional but incomplete for comprehensive design evaluation.

Resources