공식 AWS Knowledge MCP Server가 인덱스하지 않는 AWS 지식 소스를 위한 Kiro Power입니다.
공식 서버는 무료이고 인증이 필요 없으며 AWS가 유지 관리하며, 이미 AWS 문서, AWS 블로그, What's New, Well-Architected, re:Post Knowledge Center 문서를 포함합니다. 이 중 무엇이든 다시 구축한다는 것은 이미 지원되는 인터페이스로 제공되는 콘텐츠를 문서화되지 않은 엔드포인트에서 스크래핑하는 것을 의미합니다.
따라서 이 Power는 공식 서버가 거부하는 것만 다룹니다. 그 경계의 기준은 read_documentation 허용 목록입니다.
소스 | 공식 서버 | 이 Power |
| 포함됨 | — |
| 포함됨 | — |
| 포함됨 | — |
| 미포함 | 전체 검색 + 전체 스레드 읽기 |
| 미포함 | 전체 인덱스 검색 + 깔끔한 마크다운 읽기 |
| 미포함 | 최근 게시물 30개만, 요약만 |
Related MCP server: NexusNote MCP Server
PATH에 uv가 필요합니다(uvx 제공). 이 Power는 자체 Python이 필요 없으며, uv가 인터프리터를 가져옵니다.
위 표에서 "포함됨" 행에 해당하는 모든 항목에는 공식 AWS Knowledge MCP Server가 필요합니다. 이 Power는 의도적으로 그 서버를 선언하지 않습니다. 이미 그 서버를 갖고 있는 클라이언트가 같은 엔드포인트에 두 번째 연결을 열어 중복된 도구 세트를 불러오지 않도록 하기 위함입니다. 아직 없다면 ~/.kiro/settings/mcp.json에 다음을 추가하세요:
{
"mcpServers": {
"aws-knowledge": {
"url": "https://knowledge-mcp.global.api.aws"
}
}
}GitHub에서 설치(팀에 권장)
Kiro → Powers 패널 → Add Custom Power → Import power from GitHub
이 저장소의 URL을 붙여넣습니다.
로컬 클론에서 설치
git clone https://github.com/hey-iam-ryan/kiro-power-aws-knowledge-plus
Kiro → Powers 패널 → Add Custom Power → Import power from a folder
클론한 디렉터리를 선택합니다.
Powers 패널 없이 — 서버를 ~/.kiro/settings/mcp.json에 직접 추가합니다:
{
"mcpServers": {
"aws-knowledge-plus": {
"command": "uvx",
"args": [
"--from",
"git+https://github.com/hey-iam-ryan/kiro-power-aws-knowledge-plus@v0.1.0",
"aws-knowledge-plus-mcp"
],
"autoApprove": ["search_aws_knowledge", "read_aws_content", "list_sources"]
}
}
}첫 실행에서 의존성 트리를 해결하는 데 몇 초가 걸리며, 이후 실행은 uv가 캐시합니다.
이 Power는 관리자를 제외한 모든 사람에게 읽기 전용입니다. 공개 GitHub 저장소에서는 협업자로 명시적으로 추가된 계정만 push할 수 있으며, 추가된 계정은 없습니다. 클론, 설치, 포크는 팀원이 설치하거나 변경할 수 있는 권한을 부여하지 않습니다.
설치는 main이 아닌 릴리스 태그에 고정됩니다. mcp.json은 @v0.1.0을 가리키므로, main이 계속 변경되어도 모든 팀원은 검토된 동일한 코드를 실행합니다. 아무도 조용히 업그레이드되지 않습니다.
변경이 필요하신가요? 이슈 또는 pull request를 열어 주세요. 관리자가 검토, 병합, 새 태그 생성까지 진행하며, 핀이 업데이트되면 팀원이 적용하게 됩니다.
새 버전 배포(관리자용):
# after merging changes to main
uv run python smoke_test.py # must pass: it hits the live sources
git tag v0.2.0 && git push origin v0.2.0
# then bump the @v0.1.0 pin in mcp.json and README.md, commit, and push도구 | 용도 |
| 모든 소스를 병렬로 검색합니다. |
| 페이지를 호스트에 따라 라우팅하여 마크다운으로 읽으며, 이어 읽기를 위한 명시적인 잘림 표시를 제공합니다. |
| 무엇이 포함되고 무엇이 포함되지 않는지, 그리고 그 이유를 보여줍니다. |
검색 스니펫은 의도적으로 짧습니다. 스니펫은 읽을 콘텐츠를 고르기 위한 참고용이지, 여기서 답을 얻는 것으로 보지 않기 때문입니다.
re:Post — 스레드의 schema.org QAPage 데이터에서 재구성되므로, 질문과 함께 모든 답변, 작성자, 날짜, 투표수, 채택된 답변 표시를 얻을 수 있습니다. HTML 스크래핑이 없으며 코드 블록은 그대로 유지됩니다.
kiro.dev docs — 게시된 마크다운 원본을 그대로 가져옵니다(/docs/steering은 /docs/steering.md를 읽음). 따라서 사이트 크롬을 제거할 필요가 없습니다.
Builder Center — 피드 요약만 제공하며, 본문을 가져오지 않았다는 명시적인 안내를 함께 표시합니다.
변수 | 기본값 | 용도 |
|
|
|
|
| 응답 캐시 TTL, 초 단위. |
|
| 요청별 타임아웃, 초 단위. |
| Chrome 계열 UA | re:Post는 브라우저가 아닌 에이전트를 거부합니다. 주의하여 재정의하세요. |
Builder Center는 구조적으로 제한. 유일한 공개 인덱스는 30개 항목의 Atom 피드이며, 그 next 링크가 자기 자신을 가리켜 이전 게시물은 탐색할 수 없습니다. 글 본문은 클라이언트 사이드에서 렌더링되어 가져오지 않습니다. 이 때문에 소스 가중치가 낮고 비활성화할 수 있습니다.
re:Post 검색 깊이. 이 사이트는 pageSize를 지원하지만 page를 지원하지 않고, 결과가 하나의 큰 페이지, 아닌, 깊은 페이징 방식으로 나오지 않습니다.
문서화되지 않은 엔드포인트. re:Post의 검색 응답은 페이지가 포함하는 __NEXT_DATA__ 페이로드에서 읽습니다. 이는 공개된 API가 아니며 변경될 수 있습니다. 어댑터는 현재 나오는 두 방식의 페이로드 형태를 모두 견디며, 둘 다 없으면 크래시하는 대신 빈 결과를 반환합니다. 그러나 사이트를 재설게이라도 수정해야 합니다.
uv sync
uv run python smoke_test.py # live checks against all three sources
uv run aws-knowledge-plus-mcp # start on stdiosmoke_test.py는 실제 사이트를 대상으로 실행되므로 일종의 카나리 역할도 합니다. 어떤 소스가 마크업이나 페이로드를 변경하면 여기서 먼저 실패하게 됩니다.
외부 요청은 각 어댑터가 선언한 호스트와 경로 접두사로 구성된 허용 목록으로 제한됩니다. 리디렉션은 한 번에 한 단계씩 추적하며 모든 단계를 다시 검증하므로, 리디렉션이 페처를 목록에 없는 호스트로 이동시킬 수 없습니다. https만 허용됩니다. 요청에는 자격 증명이 포함되지 않으며, 모든 소스는 공개입니다.
Apache-2.0
List the sources this server covers, their limits, and what it deliberately omits.
Call this when unsure whether a lookup belongs here or with the official AWS Knowledge MCP Server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the tool's scope and even its deliberate omissions, but it does not explicitly state side-effect-freedom or other behavioral details; the 'List' framing implies a read operation without being emphatic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the purpose and immediately give the usage context. All every sentence earns its place; there is no repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no arguments and an output schema exists, so the description only needs to say what the tool is for and when to call it, which it does completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter ambiguities for the description to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List the sources this server covers, their limits, and what it deliberately omits.' This clearly distinguishes the tool from the search/read sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Call this when unsure whether a lookup belongs here or with the official AWS Knowledge MCP Server,' giving a direct when-to-use condition and pointing to the appropriate alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page from a supported source and return it as markdown.
Dispatches on the URL's host:
repost.aws/questions/<id> — the question plus every answer, rebuilt from
the page's schema.org QAPage data with authors, dates and vote counts.
kiro.dev/docs/... — the published markdown twin of the page, so the text
arrives without site chrome. Blog and changelog pages are converted from HTML.
builder.aws.com/content/... — title, plus a summary when the site's feed
published one. The body is client-rendered and is not retrieved, and the
response says so; hand the user the URL rather than paraphrasing what came
back. A title derived from the URL slug is flagged in meta.title_source.
Long pages are truncated with an explicit marker telling you the
start_index to resume from.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL returned by search_aws_knowledge. | |
| max_length | No | Maximum characters to return. | |
| start_index | No | Character offset, for continuing a long read. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It explicitly discloses client-rendered builder.aws.com bodies are not retrieved, that titles from URL slugs are flagged in meta.title_source, that repost.aws content is rebuilt from schema.org, that kiro.dev uses a markdown twin, and that long pages are truncated with an explicit resume marker. This is unusually transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a single-sentence summary, then uses a compact bulleted dispatch list for the distinct URL types, and closes with the important truncation behavior. Every sentence contributes unique information, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema already exists and the three parameters are fully described in the schema, the description does not need to restate return-value details or parameter defaults. It covers everything else an agent must know: which hosts are supported, what to expect from each, the client-rendered caveat, and the pagination/resumption mechanism.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful behavioral context beyond the schema, particularly that long pages contain an explicit marker telling the agent which start_index to use next, and that the URL's host determines the extraction behavior. This is meaningful but not a large amount of added parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific action and object: 'Fetch a page from a supported source and return it as markdown.' The host-based bullets further define exactly what each URL type yields, and the tool is clearly distinct from its siblings (search_aws_knowledge and list_sources), making it easy for an agent to know this is the content-fetching tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical, source-specific usage guidance, such as not paraphrasing builder.aws.com content and resuming long reads using the returned start_index. It does not explicitly contrast this tool with its siblings, though the schema states the URL comes from search_aws_knowledge, so the intended workflow is clear but slightly implicit in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search AWS knowledge sources that the official AWS Knowledge MCP Server does not cover.
Use this for: troubleshooting threads where someone hit the same error ('repost'), anything about Kiro itself such as steering, hooks, specs, powers or MCP configuration ('kiro'), and the AWS Builders' Library or other community write-ups ('builder').
The Builders' Library is worth calling out: aws.amazon.com/builders-library/
redirects to Builder Center, and the official server refuses the redirect
target, so this is the only way to find those articles here. Note that Builder
Center results carry no article body — see read_aws_content.
Do NOT use this for AWS service documentation, API references, AWS blogs, What's New announcements, Well-Architected guidance or re:Post Knowledge Center articles — the official AWS Knowledge MCP Server indexes those and is the better answer for them.
Sources are queried in parallel; one slow or broken source degrades to an
entry in errors rather than failing the call. Snippets are kept short on
purpose: pick the promising hits and pass their URLs to read_aws_content.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum hits to return. | |
| query | Yes | What to look for. Plain keywords work best. | |
| sources | No | Restrict the search to these sources: 'repost' (AWS re:Post community Q&A threads), 'kiro' (kiro.dev docs, blog, changelog), 'builder' (AWS Builder Center, including the AWS Builders' Library). Omit to search all of them. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full disclosure burden, and it delivers: parallel source querying, degraded single-source errors becoming entries in `errors` rather than failing the call, intentionally short snippets, the Builders' Library redirect quirk, and the caveat that Builder Center results carry no article body. These are exactly the behaviors an agent needs to calibrate expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each paragraph earns its place: purpose, in-scope uses, exclusions, a redirect quirk callout, fail-degrade behavior, and a follow-up routing to read_aws_content. It is front-loaded with the purpose statement and organized in clear sections. There is minor redundancy (the Builders' Library is mentioned in the in-scope list and again in the callout), but the callout adds vital context, so the verbosity is largely justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a search tool with only 3 parameters and an output schema, and the description covers everything an agent needs: what to search, when to search, when not to search, what each source maps to, failure behavior, and what to do with the results (pass URLs to read_aws_content). Combined with schema + output schema coverage, nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds real value: it maps source values to intent ('repost' → troubleshooting threads; 'kiro' → steering/hooks/specs/MCP config; 'builder' → Builders' Library and community write-ups), explains why `builder` is non‑obvious in the redirect paragraph, and gives advice on how to proceed from the (short) snippets. It doesn't add much for `limit`, but the source semantics are significantly enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence explains the specific action and scope: 'Search AWS knowledge sources that the official AWS Knowledge MCP Server does not cover.' It then enumerates the concrete resource categories ('repost', 'kiro', 'builder'), and contrasts itself with both the official server and its sibling read_aws_content, leaving no ambiguity about what this tool is and is not.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is exemplary: it gives a 'Use this for:' list with concrete examples (error threads, Kiro config, Builders' Library), then a 'Do NOT use this for:' list (service docs, API references, AWS blogs, What's New, etc.) with the explicit alternative recommendation: 'the official AWS Knowledge MCP Server ... is the better answer for them.' It also routes follow-on behavior to read_aws_content. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.1search_aws_knowledge1 field changedInput schema / properties / sources / descriptionPrevious value: -"Restrict the search to these sources: 'repost' (AWS re:Post community Q&A), 'kiro' (kiro.dev docs, blog, changelog), 'builder' (recent AWS Builder Center posts). Omit to search all of them."New value: +"Restrict the search to these sources: 'repost' (AWS re:Post community Q&A threads), 'kiro' (kiro.dev docs, blog, changelog), 'builder' (AWS Builder Center, including the AWS Builders' Library). Omit to search all of them."v0.1.0list_sourcesread_aws_contentsearch_aws_knowledgeScored across 3 tools
Each tool has a clearly distinct role: search for finding content, list_sources for orienting on scope, and read_aws_content for retrieving a specific page. The descriptions explicitly cross-reference each other to prevent confusion.
All three tool names follow a consistent verb_noun snake_case pattern: search_aws_knowledge, list_sources, read_aws_content. The naming style is uniform and predictable.
Three tools is well-scoped for a focused supplementary server that deliberately covers only what the official AWS Knowledge MCP Server misses. Each tool fills an essential role in the search-and-read workflow without bloat.
The server covers the full intended lifecycle: discover what sources exist (list_sources), search them (search_aws_knowledge), and retrieve specific content (read_aws_content). This is a complete minimal surface for a supplemental knowledge server.
The AWS Knowledge MCP server is a fully managed remote Model Context Protocol server that provides real-time access to official AWS content in an LLM-compatible format. It offers structured access to AWS documentation, code samples, blog posts, What's New announcements, Well-Architected best practices, and regional availability information for AWS APIs and CloudFormation resources. Key capabilities include searching and reading documentation in markdown format, getting content recommendations, listing AWS regions, and checking regional availability for services and features.
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Make your knowledge agent-ready. One MCP endpoint, 5 connectors, 3 search modes.
Search and query nTop's knowledge base and engineering guides from AI applications.
