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

krds-a11y-mcp

by kim-dongho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

컴포넌트 접근성 요건 조회

get_requirements
Read-onlyIdempotent

Retrieve a component's accessibility requirements without markup, including required inputs, guarantees, evidence, delegated page-level items, and open questions for code or design review.

Instructions

마크업 없이 컴포넌트 하나의 접근성 요건만 조회한다 — 필수 입력(필드명·규칙), 보장 항목과 근거, 페이지 수준으로 위임되는 항목, 아직 판정되지 않은 질문. 코드 리뷰·설계 검토용이다. 마크업이 필요하면 get_component를 부른다. 반환: 마크다운.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "componentId": "<componentId>"
    },
    "name": "get_requirements"
  }
}

Input Schema

NameRequiredDescriptionDefault
componentIdYes컴포넌트 id — 'krds:button' 또는 'button'. 목록은 list_components

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.0
    • changedInput schema / properties / componentId / description
      Previous value: -"컴포넌트 id — 'krds:button' 또는 'button'"New value: +"컴포넌트 id — 'krds:button' 또는 'button'. 목록은 list_components"
  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/openWorld=false/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the payload (guaranteed items with rationale, items delegated to page level, unresolved questions) and the return format (markdown). It stops short of describing behavior for an invalid or unknown componentId, which would round this out.

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 tightly packed sentences: purpose and scope first, content inventory second, alternative routing and return format last. Every clause carries information and the scope constraint 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?

With no output schema, the description correctly takes on the burden of describing what comes back, listing the four content categories and the markdown format. For a one-parameter read tool this is nearly complete; only error/unknown-id behavior is unaddressed.

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% and the single parameter is documented in-schema with both id forms ('krds:button' or 'button') and a pointer to list_components, so the description has little left to explain. The phrase '필수 입력(필드명·규칙)' could be mistaken for parameter guidance but actually describes returned content, so the description adds no parameter meaning beyond the schema. 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?

Names a specific verb and resource (접근성 요건 조회 for a single component) and adds the key scope qualifier '마크업 없이', which distinguishes it from the markup-bearing sibling. It also enumerates what the response contains (필수 입력, 보장 항목과 근거, 페이지 위임 항목, 미판정 질문), so an agent knows exactly what kind of answer this tool yields.

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?

States the intended context ('코드 리뷰·설계 검토용') and gives an explicit alternative with the selecting condition: '마크업이 필요하면 get_component를 부른다'. That is a clean when-to-use / when-to-use-something-else pair with no inference required.

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