aws-knowledge-plus

read_aws_content

Fetch pages from re:Post, kiro.dev, or AWS Builder Center, returning content as markdown with hints for resuming long reads.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 23, 2026

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.

Deploy Server