Skip to main content
Glama

MotionSpec — verified web motion (reduced-motion / WCAG)

by io.github.MasterPlayspots

Audit a live URL for motion accessibility (WCAG 2.2.2 / 2.3.3)

motion_audit
Read-only

Requires a Dev Key ($39) or Agency plan ($249/mo) on the hosted endpoint (motionspec.dev/pricing). Static motion-a11y checker: fetches a URL's HTML + linked stylesheets and scans the CSS for (1) animation/transition without a prefers-reduced-motion guard, (2) animated non-transform/opacity properties, (3) infinite animations with no pause path, (4) /autoplay >5s. Runtime motion (WAAPI/GSAP/JS) is disclosed as 'not audited (V2)'. Returns {ok, score, findings, summary, badge, disclosures, markdown}; a clean site earns the badge 'reduced-motion-safe'. Does network I/O (openWorldHint).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoThe page URL to audit (http/https).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A3.5/5.0
Behavior1/5

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

The description explicitly says 'Does network I/O (openWorldHint)' while the annotations declare openWorldHint: false. This is a direct contradiction. It otherwise adds useful details such as the paid-plan requirement and the exact return object, but the contradiction forces a 1 per the scoring rubric.

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?

Dense but well organized: prerequisite is front-loaded, the four checks are numbered, runtime limitations are disclosed, and the return shape is compactly listed. It is longer than the average description, but nearly every clause carries useful information.

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 a single parameter and no output schema, the description covers inputs, the four audit criteria, the runtime limitation, the return object, and the badge criterion. It doesn't explain score ranges or findings structure, but for this tool's complexity it is largely complete. The openWorldHint contradiction is a notable correctness gap.

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 coverage is 100% and the only parameter, url, is already described in the schema as 'The page URL to audit (http/https)'. The description adds context about fetching the URL's HTML and stylesheets but does not add new parameter-level constraints or semantics beyond 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?

States a specific verb ('audit'), resource ('a live URL'), and the exact accessibility goal (motion accessibility, WCAG 2.2.2 / 2.3.3). It enumerates four distinct CSS checks, making the tool's scope unambiguous and separating it from sibling tools by explicitly marking it as a static checker.

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?

Clearly frames the tool as a static CSS-only motion-a11y checker, notes that runtime motion (WAAPI/GSAP/JS) is not audited, and gives a pricing prerequisite. It does not explicitly name alternatives or state when not to use it, but the static-vs-runtime distinction is strong contextual guidance.

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

All MotionSpec — verified web motion (reduced-motion / WCAG) 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.1/5.0
Disambiguation5/5

Each tool targets a distinct phase in the motion-spec workflow: auditing a live URL, browsing the primitive catalog, validating a spec, compiling it, and viewing telemetry. The only potential overlap is that compile also validates, but the descriptions clearly separate validation as a pre-check and compile as the code-generation step.

Naming Consistency4/5

All tools share the consistent 'motion_' prefix, making the family instantly recognizable. The second part mixes verbs (audit, compile, validate) with nouns (catalog, stats), which is a minor deviation from a strict verb_noun pattern but still predictable and easy to navigate.

Tool Count5/5

Five tools is a well-scoped set for a domain focused on authoring, validating, compiling, auditing, and monitoring motion specs. Each tool earns its place and the count is squarely in the ideal range for a cohesive server.

Completeness4/5

The core lifecycle is covered: discover primitives, validate, compile, audit external sites, and review telemetry. The main gap is runtime-motion auditing, which is explicitly deferred to V2, and there is no tool for managing/deploying compiled specs, but these are minor and don't block the primary workflow.

Resources