Skip to main content
Glama
Sign In
krds-a11y-mcp

krds-a11y-mcp

by kim-dongho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

페이지 시각 상태 점검

inspect_page
Read-onlyIdempotent

Reads computed styles (color, background, font, size, layout, spacing) from a rendered page to verify what elements actually look like, without writing temporary browser scripts.

Instructions

렌더된 페이지에서 요소의 계산 스타일(색·배경·폰트·크기·배치·margin·padding·gap)과 폰트 적용 여부를 읽는다. '이 요소가 무슨 색인가', '폰트가 진짜 적용됐나(시스템 폰트 폴백인가)', '어디에 배치됐나'를 확인할 때 임시 playwright 스크립트를 만들지 말고 이 도구를 쓴다. 파일을 쓰지 않는다. 접근성 판정(위반·KWCAG 항목)은 validate_page를 쓴다. 반환: 마크다운 — 문서 제목, 본문 폰트 적용 여부, 셀렉터마다 배치·색·폰트·간격.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "inspect_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlNo점검할 페이지 URL(http/https). url·filePath·html 중 정확히 하나만 준다
htmlNoHTML 문자열 — 최후 수단. url·filePath·html 중 정확히 하나만 준다
filePathNo점검할 로컬 HTML 파일 경로(프로젝트 루트 기준). url·filePath·html 중 정확히 하나만 준다
selectorsNo점검할 CSS 셀렉터(최대 20개) — 각 셀렉터의 첫 매칭 요소를 읽고 매칭 개수를 함께 준다. 예: ["h1", ".krds-btn.primary", "#main-content"]. 비우면 문서 제목과 본문 폰트만 준다

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.2.0
    • changedInput schema / properties / filePath / description
      Previous value: -"점검할 로컬 HTML 파일 경로"New value: +"점검할 로컬 HTML 파일 경로(프로젝트 루트 기준). url·filePath·html 중 정확히 하나만 준다"
    • changedInput schema / properties / html / description
      Previous value: -"HTML 문자열 — 최후 수단"New value: +"HTML 문자열 — 최후 수단. url·filePath·html 중 정확히 하나만 준다"
    • changedInput schema / properties / selectors / description
      Previous value: -"점검할 CSS 셀렉터 목록 (각각 첫 매칭 요소를 읽음)"New value: +"점검할 CSS 셀렉터(최대 20개) — 각 셀렉터의 첫 매칭 요소를 읽고 매칭 개수를 함께 준다. 예: [\"h1\", \".krds-btn.primary\", \"#main-content\"]. 비우면 문서 제목과 본문 폰트만 준다"
    • changedInput schema / properties / url / description
      Previous value: -"점검할 페이지 URL (http/https)"New value: +"점검할 페이지 URL(http/https). url·filePath·html 중 정확히 하나만 준다"
    • addedInput schema / properties / url / pattern
      Added value: +"^https?:\\/\\/"
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description reinforces this with '파일을 쓰지 않는다' (no file writes). It also describes the return shape (markdown with title, body font, per-selector layout/color/font/spacing), which goes beyond annotations. Minor gap: nothing on performance/network behavior for fetching URLs, though openWorldHint covers remote access.

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?

Front-loaded with the capability, then alternatives, then return format; every sentence carries weight. Slightly dense with parenthetical examples, but none is wasteful.

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?

No output schema exists, and the description compensates by specifying the markdown return contents. Combined with 100% schema coverage and read-only annotations, an agent has everything needed to call it 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 coverage is 100% and each parameter (url/html/filePath mutual exclusivity, selectors max 20 with example) is already documented in the schema. The description adds little parameter-level semantics beyond reaffirming the tool reads per-selector styled output, so baseline 3 applies.

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 (읽는다/reads) and the exact resources it extracts from a rendered page — computed color, background, font, size, layout, margin/padding/gap, and whether the font actually applied. It is clearly separable from sibling validate_page, which handles accessibility judgment.

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?

Explicitly names the alternative workflows it replaces ('임시 playwright 스크립트를 만들지 말고 이 도구를 쓴다') and routes accessibility/KWCAG checks to validate_page. Both when-to-use and when-not-to-use are stated.

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

Deploy Server

Other Tools