一个 Kiro Power，为官方 AWS Knowledge MCP Server未建立索引的 AWS 知识源提供支持。
官方 Server 免费、无需身份验证、由 AWS 维护，并且已经覆盖了 AWS 文档、AWS 博客、What's New、Well-Architected 以及 re:Post Knowledge Center 文章。重新构建其中任何部分，都意味着通过未公开的端点抓取那些已经可以经由受支持接口获得的内容。
因此，这个 Power 只覆盖官方 Server 未收录的内容。它的 read_documentation 允许列表是权威边界：
来源 | 官方服务器 | 本 Power |
| 已覆盖 | — |
| 已覆盖 | — |
| 已覆盖 | — |
| 未覆盖 | 完整搜索 + 完整线索阅读 |
| 未覆盖 | 完整索引搜索 + 干净的 markdown 阅读 |
| 未覆盖 | 仅最近 30 篇文章的摘要 |
Related MCP server: NexusNote MCP Server
uv 需要位于 PATH 中（它提供 uvx）。此 Power 不需要自带 Python；uv 会获取一个解释器。
官方 AWS Knowledge MCP Server 负责上述“已覆盖”的全部内容。此 Power 刻意不声明它，这样已经拥有该 Server 的客户端就不会再打开到同一端点的第二个连接，从而重复载入一组工具。如果你还没有官方 Server，请在 ~/.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-knowledge-plus
打开 Kiro → Powers 面板 → 添加自定义 Power → 从文件夹导入 Power
选择刚刚克隆好的目录
Power 面板** – 直接将服务器添加到 ~/.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 仓库中，只有被明确添加为协作者（collaborator）的账户才能推送，而现在没有这样的账户。因此，克隆、安装或 fork 不会赋予你任何能力，无法更改团队成员所安装的内容。
安装是锁定到发布标签（tag），而不是 main。 mcp.json 指向 @v0.1.0，即使 main 分支仍在推进，每个队友运行的依然是同一份经过审查的代码。没有人会被偷偷升级。
需要修改？开一个 issue 或 pull request。维护者会审查、合并并发布一个新的标签；队友们则会在 pin 对应升级后接收到更新。
发布新版本（维护者操作）：
# 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工具 | 用途 |
| 并行在内部所有来源搜索。 |
| 以 markdown 形式读取页面，随站获取（按主机名分发），并带有明确的截断标记以便后续续读。 |
| 说明哪些已收录，哪些未收录，以及原因。 |
搜索摘要有意保持简短：它是为了帮助你挑选要读取的内容、而非据此直接回答。
重新发布（re:Post） 、（雷火）.pages — 它是从主题的 schema.org QAPage 数据重建的，因此你可以同时拿到问题以及每一篇回答（含作者、日期、投票数、已标记采纳的答案）。无 HTML 抓取，代码块也能完整保留。
kiro.dev 文档 — 直接读取其发布为 .md 的孪生版本（/docs/steering 读 /docs/steering.md），因此没有站点装修 shell 需要拆除。
Builder Center — 仅有 feed 摘要，并明确注明不进行正文获取。
变量 | 默认值 | 用途 |
|
| 设置为 |
|
| 响应缓存 TTL（秒）。 |
|
| 每次请求的超时时间（秒）。 |
| Chrome-like UA | re:Post 会对非浏览器代理发起质询。覆盖此值，请谨慎。 |
Builder Center 的精细度受限。 其唯一的公共索引是 next 循环自身 30 向自己头的 Atom feed，因此无法追踪更早的 posting。文章正文在客户端渲染，未包获取。所以该来源权重低、也便载入时可调。
re:Post 搜索深度。 站点支持 pageSize 但忽略 page，所以结果在前后的更多单页中，深度分页不可用。
未备案的接口。 re:Post 的 search 响应是从其自身页面中附带 __NEXT_DATA__ 读取的。它不是已公开 API 且可能变化。适配对这种当前可能的两种 payload shape 做兼容；例外情况下找不到这两种 shape 也会回到空结果，而非崩溃，但游戏 site 重设计后仍可能需要修修复。
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 将连接真实的网站，因此它同时充当一个 canary（金丝雀）：若服务方改变了其 markup 或 payload，会首先在这个文件中出现失败。
对外 HTTP 请求会根据每个 adapter 显式声明的 host 和 path 前缀构建一个 allow-list 并加以限制。重定向逐跳跟随，并且每一跳都会被重新检查、不允许让抓取器走到了不在名单上的 host。只接受 https。请求不会携带任何凭据，所有目标 source 均为公开。
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.
