Skip to main content
Glama
deenesjakoruzh
hey-iam-ryan

aws-knowledge-plus

by hey-iam-ryan
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

aws-knowledge-plus

A Kiro Power for the AWS knowledge sources the official AWS Knowledge MCP Server does not index.

Why this exists

The official server is free, unauthenticated, maintained by AWS, and already covers AWS documentation, AWS blogs, What's New, Well-Architected, and re:Post Knowledge Center articles. Rebuilding any of that would mean scraping undocumented endpoints for content already available through a supported interface.

So this power covers only what the official server rejects. Its read_documentation allow-list is the authoritative boundary:

Source

Official server

This power

docs.aws.amazon.com (incl. Well-Architected)

Covered

—

aws.amazon.com/blogs, What's New

Covered

—

repost.aws/knowledge-center

Covered

—

repost.aws/questions (community Q&A)

Not covered

Full search + full thread read

kiro.dev (docs, blog, changelog)

Not covered

Full index search + clean markdown read

builder.aws.com (Builder Center, incl. AWS Builders' Library)

Not covered

Finds articles across the published archive; no article bodies

aws.amazon.com/builders-library/ redirects to Builder Center, and the official server refuses the redirect target, so the Builders' Library is unreachable through it. That redirect is the single clearest example of why this power exists.

The boundary above is not a fixed list: it is whatever the official server's own allow-list happens to be, which AWS changes over time. Its read_documentation error message names the current allow-list verbatim, so treat that as the live source of truth and this table as a snapshot. If AWS starts indexing one of these three, the corresponding source here becomes redundant and should be dropped rather than kept for its own sake.

Related MCP server: NexusNote MCP Server

Prerequisites

  • uv on PATH (provides uvx). The power needs no Python of its own; uv fetches an interpreter.

  • The official AWS Knowledge MCP Server, for everything in the "Covered" rows above. This power deliberately does not declare it, so that clients which already have it do not open a second connection to the same endpoint and load a duplicate set of tools. If you do not have it yet, add this to ~/.kiro/settings/mcp.json:

    {
  "mcpServers": {
    "aws-knowledge": {
      "url": "https://knowledge-mcp.global.api.aws/mcp"
    }
  }
}

Install

From GitHub (recommended for teams)

  1. Kiro → Powers panel → Add Custom Power → Import power from GitHub

  2. Paste this repository's URL

From a local clone

  1. git clone https://github.com/hey-iam-ryan/kiro-power-aws-knowledge-plus

  2. Kiro → Powers panel → Add Custom Power → Import power from a folder

  3. Select the cloned directory

Without the Powers panel — add the server straight to ~/.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.2.1",
        "aws-knowledge-plus-mcp"
      ],
      "autoApprove": ["search_aws_knowledge", "read_aws_content", "list_sources"]
    }
  }
}

The first launch resolves the dependency tree and takes a few seconds; later launches are cached by uv.

The server is keyed sources in the power's own mcp.json but aws-knowledge-plus in the snippet above, and that difference is deliberate. Kiro registers a power's servers as power-<powerName>-<serverName>, so keying it aws-knowledge-plus inside a power of the same name would resolve to power-aws-knowledge-plus-aws-knowledge-plus. The prefix already carries the power name. Nothing namespaces a server you add to mcp.json yourself, so there the full name is the useful one.

Using this power in a team

This power is read-only for everyone except the maintainer. On a public GitHub repository, only accounts explicitly added as collaborators can push, and none are. Cloning, installing and forking do not grant any ability to change what your teammates install.

Installs are pinned to a release tag, not to main. mcp.json points at @v0.2.1, so every teammate runs the same reviewed code even while main moves on. Nobody is silently upgraded.

Need a change? Open an issue or a pull request. The maintainer reviews it, merges it, and cuts a new tag; teammates pick it up when the pin is updated.

Shipping a new version, for the maintainer. The pin has to be bumped before tagging, otherwise the tag ships the previous version's pin and teammates installing it get the older code:

uv run python smoke_test.py                    # must pass: it hits the live sources

# 1. bump the version and the pin together
#    - pyproject.toml   version = "0.3.0"
#    - plugin.json      "version": "0.3.0"
#    - mcp.json         ...@v0.3.0
#    - README.md        every @v0.2.1 occurrence
git commit -am "Release v0.3.0"
git push origin main

# 2. only now tag the commit that carries the correct pin
git tag -a v0.3.0 -m "v0.3.0"
git push origin v0.3.0

Release tags are protected against deletion and force-moves, so a published tag cannot be repointed. A mistake in a release is corrected by shipping the next version, not by rewriting the last one.

Tools

Tool

Purpose

search_aws_knowledge(query, sources?, limit?)

Search all sources in parallel. sources accepts repost, kiro, builder. A slow or broken source degrades to an errors entry instead of failing the call.

read_aws_content(url, start_index?, max_length?)

Read a page as markdown, dispatched by host, with explicit truncation markers for resuming.

list_sources()

What is covered, what is not, and why.

Search snippets are intentionally short: they exist to help pick what to read, not to answer from.

What the reads look like

  • re:Post — rebuilt from the thread's schema.org QAPage data, so you get the question plus every answer with authors, dates, vote counts, and the accepted-answer marker. No HTML scraping, and code blocks survive intact.

  • kiro.dev docs — fetched from the published markdown twin (/docs/steering reads /docs/steering.md), so there is no site chrome to strip.

  • Builder Center — title, plus a summary when the site's feed published one, and an explicit note that the body was not retrieved. Discovery walks the site's sitemaps, whose location is read from robots.txt rather than assumed, so the whole published archive is searchable rather than just what a feed happens to expose.

Configuration

Variable

Default

Purpose

AWS_KNOWLEDGE_PLUS_ENABLE_BUILDER

1

Set 0 to drop Builder Center from federated search.

AWS_KNOWLEDGE_PLUS_BUILDER_MIN_SCORE

0.34

Relevance floor for Builder Center. Slug matching is noisier than matching real titles, so raise it to cut community noise or lower it to surface more.

AWS_KNOWLEDGE_PLUS_CACHE_TTL

900

Response cache TTL, seconds.

AWS_KNOWLEDGE_PLUS_TIMEOUT

20

Per-request timeout, seconds.

AWS_KNOWLEDGE_PLUS_USER_AGENT

Chrome-like UA

re:Post challenges non-browser agents. Override with care.

Known limitations

  • Builder Center gives you the article, not its text. Bodies render client-side; the page's only ld+json block is a generic WebSite record, <head> carries site-wide boilerplate, and unauthenticated paths on the site's backend answer 403. Search finds the right article and hands over the URL. Titles come from the site's feed for recent posts and are otherwise derived from the URL slug, which the result discloses in meta.title_source. Topic hubs under /learn/ contain no readable text at all.

  • re:Post search depth. The site honours pageSize but not page, so results come from a single larger page rather than deep pagination.

  • Undocumented endpoints. re:Post's search response is read from the __NEXT_DATA__ payload its own page embeds. That is not a published API and can change. The adapter tolerates both payload shapes it currently emits and returns an empty result rather than crashing if neither is found, but a redesign of the site would need a fix here.

Development

uv sync
uv run python smoke_test.py     # live checks against all three sources
uv run aws-knowledge-plus-mcp   # start on stdio

smoke_test.py hits the real sites, so it doubles as a canary: if a source changes its markup or payload, it fails there first.

Security

Outbound requests are restricted to an allow-list built from each adapter's declared host and path prefixes. Redirects are followed one hop at a time and every hop is re-validated, so a redirect cannot walk the fetcher onto an unlisted host. Only https is accepted. Requests carry no credentials, and every source is public.

License

Apache-2.0

Available Tools

3 tools
list_sourcesA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior3/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 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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

read_aws_contentA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL returned by search_aws_knowledge.
max_lengthNoMaximum characters to return.
start_indexNoCharacter offset, for continuing a long read.

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.7/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_knowledgeA

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum hits to return.
queryYesWhat to look for. Plain keywords work best.
sourcesNoRestrict 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.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.8/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev0.2.1
    • Changedsearch_aws_knowledge1 field changed
      • changedInput schema / properties / sources / description
        Previous 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."
  2. 3 tool updatesv0.1.0
    • First observedlist_sources
    • First observedread_aws_content
    • First observedsearch_aws_knowledge
Deploy Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • DeepSearch MCP

    yuemingruoan
    A
    license
    B
    quality
    C
    maintenance
    Enables web search and site-specific search capabilities through the Deepsearch model. Provides unified access to broad web retrieval and targeted site search functionality within the MCP ecosystem.
    2
    8
    5
    Apache 2.0

  • NexusNote MCP Server

    karan19
    F
    license
    Not graded
    quality
    D
    maintenance
    Enables debate search and citation functionality through web search, Wikipedia, arXiv, and AWS documentation APIs. Designed to power debate features with comprehensive research and citation tools via MCP protocol.
    -

  • Ollama Web Search

    deXterbed
    A
    license
    A
    quality
    B
    maintenance
    Enables web search and web fetch operations using Ollama's hosted APIs, allowing MCP clients to search the web and retrieve page content.
    2
    MIT