swwa-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool occupies a clear role: contrast checking, browser environment probing, checkpoint lookup, checklist construction, static HTML auditing, live URL auditing, and readiness estimation. The only similar pair (check_html vs audit_url) is explicitly separated by static-vs-browser behavior.
Naming Consistency4/5
Names use a consistent snake_case format and mostly follow a verb_noun pattern (check_contrast, lookup_checkpoint, get_checklist, check_html, audit_url, estimate_cert_readiness). browser_status breaks the verb pattern slightly, but remains readable and unambiguous.
Tool Count5/5
Seven tools is well-scoped for an accessibility-audit MCP server. Each tool maps to a necessary step in the workflow (preflight, static/dynamic audit, contrast, checklist, readiness) without redundancy.
Completeness4/5
The server covers the main audit lifecycle: static analysis, browser-based dynamic analysis, contrast checking, checklist creation, and readiness aggregation. A minor gap is that manual/user assessment results cannot be recorded, though estimate_cert_readiness does acknowledge that residual.
Average 4/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/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. It discloses that the tool creates a checklist and lists scopes, but does not describe output format, whether the operation has side effects, authentication needs, or any behavioral quirks. For a tool with no annotation coverage, this is insufficient behavioral transparency.
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 sentence, front-loaded with the core action and scope. Every part contributes to understanding the tool's purpose, with no redundant or irrelevant material.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations and no output schema, so the description alone must provide sufficient context. It explains the purpose but omits usage guidance, return value/format, and behavioral caveats. Given the presence of siblings and a required scope parameter, the definition is not fully complete for an agent to invoke it correctly without extra assumptions.
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 67%, so the baseline for this dimension is neutral. The description adds the scope categories (검사항목/컴포넌트/페이지/사용자 평가), which map to the scope enum, but it does not add meaning for the id or component parameters beyond what the schema already provides. This is adequate but not compensatory.
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 ('만든다' - creates) and a specific resource ('KWCAG 2.2 체크리스트'), and enumerates the four scope types. This clearly distinguishes get_checklist from siblings like check_contrast, check_html, audit_url, and lookup_checkpoint, which are inspection/lookup tools rather than generation tools.
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?
There is no explicit guidance about when to use this tool versus alternatives, no exclusions, and no mention of sibling tools. The scope list hints at use cases, but the description does not state e.g. 'use when you need to create a checklist by scope' or 'use lookup_checkpoint for individual checkpoint details.'
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?
Annotations already cover read-only, non-destructive, and idempotent behavior, so the description only needs to add contextual detail. It adds the accepted lookup keys and KWCAG 2.2 version, but it does not clarify what summary vs full returns or how results are formatted. No contradiction exists.
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?
A single front-loaded sentence states the resource, action, and all supported query forms with no filler. It is compact and easy for an agent to scan.
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 read-only lookup tool with a simple two-parameter schema and clear annotations, the description conveys the query scope needed for correct invocation. The summary/full payload difference is left unspecified, but that does not prevent an agent from selecting or calling the tool correctly.
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 roughly 50%: the query parameter has a description, while detail has only an enum and default. The description repeats much of the query schema content but adds 'alias' and 'wcag:' prefix semantics; it does not clarify the difference between summary and full.
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 uses a specific verb ('조회한다'), names the resource ('KWCAG 2.2 검사항목'), and enumerates the query dimensions (official ID/alias, WCAG SC, axe rule ID, keyword). It does not explicitly differentiate from sibling tools such as get_checklist, so some sibling distinction is left to inference.
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 the look-up use case: call this when you need KWCAG items by ID, WCAG SC, axe rule, or keyword. However, it gives no explicit when-to-use or when-not-to-use guidance, nor alternatives, so an agent must infer how it relates to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=true already provided, the description adds meaningful behavioral context: it launches a real browser, runs axe plus dynamic checks (focus, target size, skip navigation), and is KWCAG-grounded. It does not contradict the annotations, though it could mention side effects like screenshots or network activity more explicitly.
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?
Two sentences, front-loaded with the core purpose and method, then a clear usage instruction and prerequisite. Every sentence earns its place with no redundant filler.
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 description covers purpose, when to use, and a prerequisite well. However, given the tool's complexity (10 params, nested objects, low schema coverage), the description does not fully prepare an agent to configure the audit correctly—especially around output handling, timeouts, and scoping options.
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 only 40% with 10 parameters, so the description carries a heavy burden to explain parameter meaning. It partially explains the 'checks' concept by naming axe, focus, target size, and skip navigation, but it does not clarify url constraints, viewport, timeoutMs, outputDir, screenshot, maxFindings, or excludeRules. This 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 states a specific action ('opens the URL in a real browser and performs an audit') and a concrete standard (KWCAG 2.2) with specific dynamic checks. This clearly distinguishes it from siblings like check_html or check_contrast, which are narrower or static checks.
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 clearly states when to call it ('site inspection / certification preparation') and gives an explicit prerequisite: check browser_status first. It does not explicitly discuss when not to use it relative to siblings, but the context and prerequisite are concrete enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the core behavior beyond the readOnlyHint annotation: it not only calculates a ratio but also returns a pass/fail judgment against a specific standard. It does not contradict the read-only annotation. Though it does not discuss invalid color handling or alpha edge cases, the read-only nature and output schema lower the burden, and the stated behavior is accurate and useful.
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, front-loaded sentence with no filler. It states the action, the object, and the evaluation standard, and every element contributes to agent understanding.
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 relatively simple two-color contrast checker, the description covers the essential purpose and standard, while required parameter formats are provided in the schema and return semantics are presumably covered by the output schema. The only notable gap is the lack of sibling comparison or explicit when-to-use guidance, but for this isolated utility the description remains 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?
The schema already documents foreground/background color formats well, covering 50% of parameters. The description adds the KWCAG criterion context but does not explain the effect of bold and fontSizePx on the threshold determination. The optional parameter semantics are mostly left to their names, defaults, and common knowledge, so the description provides only modest extra meaning over 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 what the tool does: it calculates the luminance contrast between two colors and determines whether the contrast passes KWCAG 5.4.3(1.4.3). The verb 'calculates' and 'judges' alongside the specific resource '두 색상 사이의 명도 대비' make the purpose unambiguous and distinguish it from sibling tools like check_html or audit_url.
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 in accessibility contrast-checking contexts via the KWCAG reference, but it does not explicitly state when to use check_contrast versus alternatives such as check_html or audit_url, nor does it provide exclusions. The intended use case is reasonably inferable, but the guidance is left to implication rather than explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the readOnlyHint annotation: it explicitly warns that automated inspection alone does not determine certification pass and that remaining manual/user review items are reported. This is valuable transparency for an estimation tool and aligns with the read-only annotation.
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?
Two sentences, both information-dense and non-redundant. The core action is front-loaded, and the important caveat about automated-only assessment is placed second without bloating the description.
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 read-only annotation, fully described parameters, and clear input sources, the description provides enough context for an agent to invoke the tool correctly. It also communicates what the output conveys: per-item compliance rates and remaining manual/user review. A fully explicit output schema would raise this further, but its absence is partly compensated by the description.
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 parameters are already documented in the schema, including the mutual exclusivity of reports/reportPaths and the default for pageCount. The tool description adds high-level context about aggregating Reports but does not add parameter-level detail beyond what the schema provides.
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 plus resource: it aggregates multiple inspection Reports into per-item compliance rates to estimate web accessibility certification readiness. It also clearly distinguishes itself from lower-level inspection tools like check_html or audit_url by operating on their outputs rather than performing inspections 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 when to use the tool: after obtaining Reports from check_html or audit_url, and when estimating overall certification readiness across multiple pages. It does not explicitly name alternatives or state when not to use it, but the input dependency and estimation purpose provide clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds meaningful behavior beyond that: it runs without a browser, performs static analysis only, and explicitly discloses that contrast, focus indication, and target size checks are not fully performed and are marked as 'browser audit required'. This is honest, specific, and materially shapes agent expectations.
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?
Three dense sentences with no filler: first states what the tool does, second states when to call it, third states the key browserless limitation. Everything earns its place and the most important information is front-loaded.
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 read-only static checker with an output schema, the description covers purpose, invocation context, and behavioral limitations well. It could be slightly stronger by explicitly naming sibling tools for the browser-required checks or clarifying network/auth assumptions, but nothing essential for correct invocation is missing.
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 67%, so most parameters are already documented. The description reinforces the html/path either-or relationship by mentioning both HTML strings and local HTML files, but it adds no new meaning for baseUrl, ruleset, maxFindings, or excludeRules. With moderate schema coverage, a baseline 3 is appropriate.
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 action (static accessibility inspection), a clear resource (HTML strings or local HTML files), and a concrete standard (KWCAG 2.2). The addition of 'static' and 'without a browser' distinguishes it from sibling tools like check_contrast and audit_url.
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?
Explicitly tells the agent when to use the tool: 'must call when writing, modifying, or reviewing web UI code'. It also implies a boundary by stating that rendering-dependent checks are only marked as needing browser audit, but it does not name specific sibling alternatives for when a browser audit is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description is consistent with that. It adds useful behavioral context beyond annotations: the ordered browser fallback chain (Chrome→Edge→Playwright chromium) and the precondition relationship with audit_url.
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 sentence that states both the tool's purpose and its usage context with zero wasted words. The key fact (check before audit_url) is prominent and easy to parse.
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?
The tool is simple: no required parameters, a fully documented optional parameter, an output schema present, and read-only annotations. The description covers the essential workflow placement and browser scope, so nothing critical is missing.
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 sole parameter refresh is fully documented in the schema (100% coverage), so the description need not repeat it. With schema coverage this high, the baseline of 3 applies; the description adds no parameter-level meaning but does not need to.
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 and resource: it checks whether the browser that audit_url will use (Chrome→Edge→Playwright chromium) is installed. It also names the related sibling audit_url, making the tool's role in the workflow immediately distinguishable.
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?
The description explicitly instructs the agent to run this check before calling audit_url. This is a clear, actionable when-to-use directive that leaves no ambiguity about placement in the workflow.
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:

[![SWWA MCP server](https://glama.ai/mcp/servers/SWJoong/SWWA/badges/card.svg)](https://glama.ai/mcp/servers/SWJoong/SWWA)

Score Badge

Copy to your README.md:

[![SWWA MCP server](https://glama.ai/mcp/servers/SWJoong/SWWA/badges/score.svg)](https://glama.ai/mcp/servers/SWJoong/SWWA)

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/SWJoong/SWWA'

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