Skip to main content
Glama

Server Details

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.

Status
Healthy
Last Tested
Transport
Streamable HTTP
URL

Glama MCP Gateway

Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.

MCP client
Glama
MCP server

Full call logging

Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.

Tool access control

Enable or disable individual tools per connector, so you decide what your agents can and cannot do.

Managed credentials

Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.

Usage analytics

See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.

100% free. Your data is private.
Tool DescriptionsA

Average 4.8/5 across 6 of 6 tools scored.

Server CoherenceA
Disambiguation5/5

Each tool has a clearly distinct purpose: checking regional availability, listing regions, reading documentation, getting recommendations, retrieving skills, and searching documentation. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'aws___<verb_noun>' pattern with underscores (e.g., 'get_regional_availability', 'list_regions'). The naming is predictable and uniform.

Tool Count5/5

With 6 tools, the set is well-scoped for an AWS knowledge server. It covers searching, reading, regional availability, recommendations, and skills without being too sparse or excessive.

Completeness5/5

The tool surface covers the full lifecycle of AWS knowledge tasks: search, read, get regional info, get recommendations, and retrieve domain skills. No obvious gaps for the stated purpose.

Available Tools

6 tools
aws___get_regional_availabilityA
Read-only
Inspect

Check AWS resource availability across regions for products (service and features), APIs, and CloudFormation resources.

Quick Reference

  • Maximum 10 regions per call (split into multiple calls for more regions)

  • Single region: filters optional, supports pagination

  • Multiple regions: filters required, no pagination, queries run concurrently

  • Status values: 'isAvailableIn' | 'isNotAvailableIn' | 'isPlannedIn' | 'Not Found'

  • Response field: 'products' (product), 'service_apis' (api), 'cfn_resources' (cfn)

When to Use

  1. Pre-deployment Validation

    • Verify resource availability before deployment

    • Prevent deployment failures due to regional restrictions

    • Validate multi-region architecture requirements

  2. Architecture Planning

    • Design region-specific solutions

    • Plan multi-region deployments

    • Compare regional capabilities

Do Not Use This Tool For

  • Counting or listing regions by geography (e.g., "how many AP regions exist?") — use list_regions then count, or use search_documentation

  • Questions about documentation, announcements, or general service availability dates — use search_documentation

  • CloudFormation resource coverage questions across all regions — use search_documentation with topic cloudformation

  • Any question that asks about availability in general without specifying a known product name, API, or CFN resource type — use search_documentation instead, as this tool requires exact resource identifiers and will return 'Not Found' for vague queries

Examples

Check specific resources in one region:

regions=["us-east-1"], resource_type="product", filters=["AWS Lambda"]
regions=["us-east-1"], resource_type="api", filters=["Lambda+Invoke", "S3+GetObject"]
regions=["us-east-1"], resource_type="cfn", filters=["AWS::Lambda::Function"]

Compare availability across regions:

regions=["us-east-1", "eu-west-1"], resource_type="product", filters=["AWS Lambda"]

Explore all resources (single region only, with pagination handling support via next_token due to large output):

regions=["us-east-1"], resource_type="product"

Follow up with next_token from response to get more results.

Response Format

Single Region: Flat structure with optional next_token. Example:

{"products": {"AWS Lambda": "isAvailableIn"}, "next_token": null, "failed_regions": null}

Multiple Regions: Nested by region. Example:

{"products": {"AWS Lambda": {"us-east-1": "isAvailableIn", "eu-west-2": "isAvailableIn"}}, ...}

Filter Guidelines

The filters must be passed as an array of values and must follow the format below.

  1. Product - service and feature (resource_type='product') Format: 'Product' Example filters:

    • ['Latency-Based Routing', 'AWS Amplify', 'AWS Application Auto Scaling']

    • ['PrivateLink Support', 'Amazon Aurora']

  2. APIs (resource_type='api') Format: to filter on API level 'SdkServiceId+APIOperation' Example filters:

    • ['Athena+UpdateNamedQuery', 'ACM PCA+CreateCertificateAuthority', 'IAM+GetSSHPublicKey'] Format: to filter on SdkService level 'SdkServiceId' Example filters:

    • ['EC2', 'ACM PCA']

  3. CloudFormation (resource_type='cfn') Format: 'CloudformationResourceType' Example filters:

    • ['AWS::EC2::Instance', 'AWS::Lambda::Function', 'AWS::Logs::LogGroup']

ParametersJSON Schema
NameRequiredDescriptionDefault
regionNoTarget AWS region code (e.g., us-east-1, eu-west-1, ap-southeast-2).
filtersNoOptional list of one or multiple specific resources to check. Format depends on resource_type: - Products: ['AWS Lambda', 'Amazon S3'] - APIs: ['IAM+GetSSHPublicKey', 'EC2'] - CloudFormation: ['AWS::EC2::Instance'] Must follow the format specified in the tool description.
regionsNoOne or more AWS region codes (e.g., us-east-1, eu-west-1). Maximum 10 regions per call. Single region supports pagination. Multiple regions require filters.
next_tokenNoPagination token from previous response for retrieving additional results. Only valid for single region queries and no filters.
resource_typeYesType of AWS resource: 'product' (AWS services/features), 'api' (SDK/API operations), or 'cfn' (CloudFormation resource types).
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the annotations (readOnlyHint, destructiveHint). It details behavioral traits such as maximum 10 regions per call, single vs multiple region behavior differences, pagination support, concurrency, status values, and response format. No contradiction with annotations.

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 lengthy but well-structured with sections (Quick Reference, When to Use, Do Not Use, Examples, Response Format, Filter Guidelines). It is front-loaded with the purpose and quick reference. While every sentence adds value, some details could be more concise, but overall it remains organized.

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 the tool's complexity (5 parameters, regional queries, pagination, multiple resource types), the description is comprehensive. It covers response format (crucial since no output schema), filter guidelines for each resource type, examples, and edge cases. It leaves no major gaps for an AI agent to misuse the tool.

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 input schema already has 100% description coverage for all 5 parameters, providing basic semantics. The tool description adds significant value by explaining filter format guidelines, the rule that multiple regions require filters, pagination usage, and response format examples. This enriches understanding beyond the schema.

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 clearly states the tool's purpose: 'Check AWS resource availability across regions for products (service and features), APIs, and CloudFormation resources.' It uses a specific verb ('check'), identifies the resource ('AWS resource availability'), and distinguishes from sibling tools by providing usage boundaries.

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 includes dedicated 'When to Use' and 'Do Not Use This Tool For' sections, explicitly listing use cases (pre-deployment validation, architecture planning) and exclusions with references to sibling tools like list_regions and search_documentation. This provides clear guidance on when to use alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

aws___list_regionsA
Read-only
Inspect

Retrieve a list of all AWS regions.

Usage

This tool provides information about all AWS regions, including their identifiers and names.

When to Use

  • When planning global infrastructure deployments

  • To validate region codes for other API calls

  • To get a complete AWS regional inventory

Do Not Use This Tool For

  • Answering questions about how many regions exist in a geography (e.g., "how many AP regions?") — use this tool to get the full list, then count from the result, or use search_documentation for a documented answer

  • Questions about service or feature availability in specific regions — use get_regional_availability for known product names, or search_documentation for general coverage questions

  • Any question that can be answered from AWS documentation — use search_documentation instead

Result Interpretation

Each region result includes:

  • region_id: The unique region code (e.g., 'us-east-1')

  • region_long_name: The human-friendly name (e.g., 'US East (N. Virginia)')

Common Use Cases

  1. Infrastructure Planning: Review available regions for global deployment

  2. Region Validation: Verify region codes before using in other operations

  3. Regional Inventory: Get a complete list of AWS's global infrastructure

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context by explaining the result structure (region_id, region_long_name) and interpretation, which is consistent with the read-only nature. It does not disclose potential pagination or sorting, but for a list of all regions, these are minor omissions.

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 well-structured with clear sections (Usage, When to Use, Do Not Use, Result Interpretation, Common Use Cases). It is front-loaded with the core purpose and each sentence adds value, with no redundancy or waste.

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 the tool has no parameters, no output schema, and annotations are present, the description provides complete context: purpose, usage guidelines, result interpretation, and common use cases. It covers all necessary information for an agent to use this tool correctly.

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 no parameters, and schema coverage is 100%. Baseline for zero parameters is 4. The description adds value by explaining the output fields (region_id, region_long_name), which is helpful for an agent to understand what to expect.

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 clearly states it retrieves a list of all AWS regions, specifying the verb 'Retrieve' and the resource 'list of all AWS regions'. It effectively distinguishes this tool from siblings like get_regional_availability and search_documentation by focusing on region inventory.

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 provides explicit when-to-use scenarios (infrastructure planning, region validation, inventory) and detailed do-not-use scenarios, including specific alternatives like search_documentation for documented answers. This offers clear guidance for the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

aws___read_documentationA
Read-only
Inspect

Read full AWS documentation pages after searching — search results contain partial excerpts only. Use this tool on the URLs returned by search_documentation to get complete, accurate information.

Usage

This tool reads documentation pages concurrently and converts them to markdown format. Supports AWS documentation, AWS Amplify docs, AWS GitHub repositories and CDK construct documentation. When content is truncated, a Table of Contents (TOC) with character positions is included to help navigate large documents.

Best Practices

  • After searching, read the most relevant URLs to get complete information — search snippets are partial excerpts and often insufficient to answer accurately

  • Batch 2-5 requests when reading multiple URLs from search results

  • Use TOC character positions to jump directly to relevant sections in long documents

  • If a document was truncated and the answer may be in the remaining content, continue reading with start_index set to the previous end_index. Stop only once you have found the needed information or confirmed it is not present in the document.

Request Format

Each request must be an object with:

  • url: The documentation URL to fetch (required)

  • max_length: Maximum characters to return (optional, default: 10000 characters)

  • start_index: Starting character position (optional, default: 0)

For batching you can input a list of requests.

Example Request

{
  "requests":
  [
      {
          "url": "https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-management.html",
          "max_length": 5000,
          "start_index": 0
      },
      {
          "url": "https://repost.aws/knowledge-center/ec2-instance-connection-troubleshooting"
      }
  ]
}

URL Requirements

Allow-listed URL prefixes:

  • docs.aws.amazon.com

  • aws.amazon.com

  • repost.aws/knowledge-center

  • docs.amplify.aws

  • ui.docs.amplify.aws

  • github.com/aws-cloudformation/aws-cloudformation-templates

  • github.com/aws-samples/aws-cdk-examples

  • github.com/aws-samples/generative-ai-cdk-constructs-samples

  • github.com/aws-samples/serverless-patterns

  • github.com/awsdocs/aws-cdk-guide

  • github.com/awslabs/aws-solutions-constructs

  • github.com/cdklabs/cdk-nag

  • constructs.dev/packages/@aws-cdk-containers

  • constructs.dev/packages/@aws-cdk

  • constructs.dev/packages/@cdk-cloudformation

  • constructs.dev/packages/aws-analytics-reference-architecture

  • constructs.dev/packages/aws-cdk-lib

  • constructs.dev/packages/cdk-amazon-chime-resources

  • constructs.dev/packages/cdk-aws-lambda-powertools-layer

  • constructs.dev/packages/cdk-ecr-deployment

  • constructs.dev/packages/cdk-lambda-powertools-python-layer

  • constructs.dev/packages/cdk-serverless-clamscan

  • constructs.dev/packages/cdk8s

  • constructs.dev/packages/cdk8s-plus-33

  • strandsagents.com/

Deny-listed URL prefixes:

  • aws.amazon.com/marketplace

Example URLs

Output Format

Returns a list of results, one per request:

  • Success: Markdown content with status: "SUCCESS", total_length, start_index, end_index, truncated, redirected_url (if page was redirected)

  • Error: Error message with status: "ERROR", error_code (not_found, invalid_url, throttled, downstream_error, validation_error)

  • Truncated content includes a ToC with character positions for navigation

  • Redirected pages include a note in the content and populate the redirected_url field

Handling Long Documents

If the response indicates the document was truncated, you have several options:

  1. Continue Reading: Make another call with start_index set to the previous end_index — do this if the answer may be in the remaining content

  2. Jump to Section: Use the ToC character positions to jump directly to specific sections

  3. Stop when done: Stop only once you have found the needed information or confirmed it is not present in the document

Example - Jump to Section:

# TOC shows: "Using a logging library (char 3331-6016)"
# Jump directly to that section:
{"requests":[{"url": "https://docs.aws.amazon.com/lambda/latest/dg/python-logging.html", "start_index": 3331, "max_length": 3000}]}
ParametersJSON Schema
NameRequiredDescriptionDefault
requestsNoList of documentation requests, each containing url, max_length (optional), and start_index (optional).
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations show readOnlyHint=true and destructiveHint=false, already indicating safety. Description adds context: converts to markdown, supports truncation with TOC, handles redirects, provides error codes. No contradiction.

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?

Well-structured with clear sections (Usage, Best Practices, Request Format, etc.) and front-loaded purpose. However, the long list of example URLs could be trimmed without losing clarity. Still very organized.

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?

Comprehensive description covering batching, truncation handling, URL restrictions, output format with success/error states, and redirects. Despite no output schema, output is well explained. Fully adequate for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds significant meaning: explains batching, default max_length, use of start_index for continuing reads, example JSON, URL requirements. Adds value beyond schema.

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 explicitly states the tool reads full AWS documentation pages to get complete information, distinguishing it from search_documentation which provides partial excerpts. The verb 'read' and resource 'full AWS documentation pages' are specific.

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?

Provides clear when-to-use: after searching with search_documentation. Includes best practices like batching 2-5 requests, using TOC for navigation, and continuing reading on truncation. Also specifies URL allow/deny lists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

aws___recommendA
Read-only
Inspect

Get content recommendations for an AWS documentation page.

Usage

This tool provides recommendations for related AWS documentation pages based on a given URL. Use it to discover additional relevant content that might not appear in search results. URL must be from the docs.aws.amazon.com domain.

Recommendation Types

The recommendations include four categories:

  1. Highly Rated: Popular pages within the same AWS service

  2. New: Recently added pages within the same AWS service - useful for finding newly released features

  3. Similar: Pages covering similar topics to the current page

  4. Journey: Pages commonly viewed next by other users

When to Use

  • After reading a documentation page to find related content

  • When exploring a new AWS service to discover important pages

  • To find alternative explanations of complex concepts

  • To discover the most popular pages for a service

  • To find newly released information by using a service's welcome page URL and checking the New recommendations

Finding New Features

To find newly released information about a service:

  1. Find any page belong to that service, typically you can try the welcome page

  2. Call this tool with that URL

  3. Look specifically at the New recommendation type in the results

Result Interpretation

Each recommendation includes:

  • url: The documentation page URL

  • title: The page title

  • context: A brief description (if available)

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL of the AWS documentation page to get recommendations for
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and non-destructive behavior. The description adds context about four recommendation categories, domain restriction to docs.aws.amazon.com, and output fields. However, it does not mention error handling or rate limits.

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 well-structured with sections and front-loaded. While some content repeats (e.g., 'Finding New Features' overlaps with usage guidelines), overall every sentence adds value and it avoids unnecessary verbosity.

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?

For a simple, read-only tool with one parameter and no output schema, the description covers usage, recommendation types, and result interpretation. It does not discuss error cases but is sufficient for typical use.

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% with one parameter (url). The description adds a crucial constraint: 'URL must be from the docs.aws.amazon.com domain.' This provides semantic value beyond the schema's bare description.

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 begins with 'Get content recommendations for an AWS documentation page.' This is a specific verb+resource+domain, clearly distinguishing it from sibling tools like aws___search_documentation or aws___read_documentation.

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?

A dedicated 'When to Use' section provides explicit scenarios, and the description contrasts with search: 'Use it to discover additional relevant content that might not appear in search results.' It also includes a special case for finding new features.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

aws___retrieve_skillA
Read-only
Inspect

Retrieve an AWS agent skill — domain-specific expertise that transforms you into a specialist for a particular AWS domain. Skills provide workflows, context, best practices, decision frameworks and step-by-step procedures. A skill may include reference files (architecture docs, schemas, examples) and deterministic workflows for sub-tasks that require exact execution.

What Skills Provide

  • Domain expertise: Deep knowledge about specific AWS services, patterns, and operational practices

  • Workflows: Guided sequences for complex tasks with appropriate degrees of freedom

  • Reference materials: Architecture docs, API references, examples, and templates accessible via the file parameter

  • Decision frameworks: Conditional logic and troubleshooting trees for navigating complex scenarios

CRITICAL PREREQUISITE — DO NOT SKIP

You MUST call search_documentation BEFORE calling this tool. NEVER call this tool first. You do NOT know skill names — they are unpredictable identifiers that can only be discovered through search_documentation results. Guessing or fabricating a skill_name WILL fail.

REQUIRED WORKFLOW (no exceptions)

  1. FIRST: Call search_documentation with the user's requirements

  2. THEN: Find the result entry that has a skill_name field

  3. FINALLY: Call this tool with the EXACT skill_name value from that result — copy it verbatim

Working with Skills

When you retrieve a skill:

  1. Read the SKILL.md overview to understand the domain and scope

  2. Follow the workflows and guidance in the skill body

  3. When the skill references additional files (e.g., [architecture](references/architecture.md)), retrieve them using this same tool with the file parameter

  4. Apply the skill's decision frameworks and conditional logic to the user's specific situation

PARAMETER REQUIREMENTS

skill_name: str (Required)

  • MUST be copied exactly from the skill_name field in search_documentation results

  • Do NOT guess, fabricate, paraphrase, or modify the name in any way

  • Do NOT use the result title — use only the skill_name field value

file: str (Optional)

  • Retrieve a specific file within the skill directory (e.g., "references/architecture.md")

  • Use this when the SKILL.md body links to reference files

  • If omitted, returns the main SKILL.md file

IF SKILL NOT FOUND

If you get an error, you likely guessed the name. Call search_documentation first to discover it. The error response will include a list of available files for the skill.

Returns

The skill content — either the main SKILL.md with domain expertise, workflows, and guidance, or a specific reference file when the file parameter is provided.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileNoOptional specific file within the skill directory (e.g., 'references/architecture.md'). Use when the SKILL.md body links to reference files. If omitted, returns the main SKILL.md.
skill_nameYesExact skill name from the skill_name field in search_documentation results (no modifications)
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true; description adds that the tool returns skill content (SKILL.md or reference files), explains the file parameter for linked files, and describes error behavior when skill not found. No contradiction with annotations.

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?

Despite length, the description is well-structured with headers and bullet points. Each section adds necessary value: purpose, prerequisites, workflow, working with skills, parameter details, and error handling. Every sentence earns its place.

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 no output schema, the description explains return values (skill content or specific file) and error behavior. It also ties to sibling tool search_documentation, covers file usage, and provides complete guidance for correct invocation.

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?

Both parameters are fully described in the input schema (100% coverage), so baseline is 3. The description adds critical usage context: skill_name must be copied exactly from search_documentation results, and file is for retrieving specific reference files. This extra guidance justifies a 4.

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 clearly states the tool retrieves an AWS agent skill with domain expertise, workflows, and reference materials. It distinguishes from siblings by specifying a prerequisite call to search_documentation, setting it apart as a follow-up tool.

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 provides when-to-use (after search_documentation) and when-not-to (never call first). Details a required three-step workflow with no exceptions, and warns against guessing skill names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

aws___search_documentationA
Read-only
Inspect

AWS Documentation Search Tool

Use this tool to find relevant AWS documentation — always follow up with read_documentation to get complete answers. Prefer this over general knowledge for AWS services, features, configurations, troubleshooting, and best practices.

When to Use This Tool

Always search when the query involves:

  • Any AWS service or feature (Lambda, S3, EC2, RDS, etc.)

  • AWS architecture, patterns, or best practices

  • AWS CLI, SDK, or API usage

  • AWS CDK or CloudFormation

  • AWS Amplify development

  • AWS errors or troubleshooting

  • AWS pricing, limits, or quotas

  • Strands Agents development

  • "How do I..." questions about AWS

  • Recent AWS updates or announcements

Only skip this tool when:

  • Query is about non-AWS technologies

  • Question is purely conceptual (e.g., "What is a database?")

  • General programming questions unrelated to AWS

Skill Suggestions for Actionable Queries

When your search query matches tasks that benefit from domain-specific expertise, this tool will suggest relevant Agent Skills. Skills package domain knowledge, workflows, best practices, decision frameworks, and reference materials that make you a specialist in a particular AWS domain.

How it works:

  • Your search query is scored against the skills registry using semantic search over skill descriptions and metadata tags

  • If your query matches a skill's domain, relevant skills are returned alongside documentation results

  • Skills cover a wide range of domains: deployment, troubleshooting, security, optimization, architecture, and more

  • To load a suggested skill, use the retrieve_skill tool with the skill_name

  • Once loaded, follow the skill's workflows and retrieve any referenced files as needed

Example queries that may return skills:

  • "deploy a web application to AWS" — may return a deployment skill with architecture guidance and step-by-step deployment instructions

  • "debug Lambda cold start issues" — may return a troubleshooting skill with diagnostic workflows

  • "secure S3 buckets" — may return a security skill with best practices and compliance checklists

  • "optimize API Gateway latency" — may return a performance skill with decision frameworks

  • "set up VPC peering" — may return a networking skill with step-by-step procedures

Quick Topic Selection

Query Type

Use Topic

Example

API/SDK/CLI code

reference_documentation

"S3 PutObject boto3", "Lambda invoke API"

New features, releases

current_awareness

"Lambda new features 2024", "what's new in ECS"

Errors, debugging

troubleshooting

"AccessDenied S3", "Lambda timeout error"

Amplify apps

amplify_docs

"Amplify Auth React", "Amplify Storage Flutter"

CDK concepts, APIs, CLI

cdk_docs

"CDK stack props Python", "cdk deploy command"

CDK code samples, patterns

cdk_constructs

"serverless API CDK", "Lambda function example TypeScript"

CloudFormation templates

cloudformation

"DynamoDB CloudFormation", "StackSets template"

Architecture, blogs, guides

general

"Lambda best practices", "S3 architecture patterns"

Strands Agents

strands_docs

"Strands Agents Python structured output", "Strands Agents AWS CDK EC2 Deployment Example"

Domain expertise, workflows, guided procedures

agent_skills

"deploy serverless app", "debug Lambda cold starts", "secure IAM policies"

Documentation Topics

reference_documentation

For: API methods, SDK code, CLI commands, technical specifications

Use for:

  • SDK method signatures: "boto3 S3 upload_file parameters"

  • CLI commands: "aws ec2 describe-instances syntax"

  • API references: "Lambda InvokeFunction API"

  • Service configuration: "RDS parameter groups"

Don't confuse with general—use this for specific technical implementation.

current_awareness

For: New features, announcements, "what's new", release dates

Use for:

  • "New Lambda features"

  • "When was EventBridge Scheduler released"

  • "Latest S3 updates"

  • "Is feature X available yet"

Keywords: new, recent, latest, announced, released, launch, available

troubleshooting

For: Error messages, debugging, problems, "not working"

Use for:

  • Error codes: "InvalidParameterValue", "AccessDenied"

  • Problems: "Lambda function timing out"

  • Debug scenarios: "S3 bucket policy not working"

  • "How to fix..." queries

Keywords: error, failed, issue, problem, not working, how to fix, how to resolve

amplify_docs

For: Frontend/mobile apps with Amplify framework

Always include framework: React, Next.js, Angular, Vue, JavaScript, React Native, Flutter, Android, Swift

Examples:

  • "Amplify authentication React"

  • "Amplify GraphQL API Next.js"

  • "Amplify Storage Flutter setup"

cdk_docs

For: CDK concepts, API references, CLI commands, getting started

Use for CDK questions like:

  • "How to get started with CDK"

  • "CDK stack construct TypeScript"

  • "cdk deploy command options"

  • "CDK best practices Python"

  • "What are CDK constructs"

Include language: Python, TypeScript, Java, C#, Go

Common mistake: Using general knowledge instead of searching for CDK concepts and guides. Always search for CDK questions!

cdk_constructs

For: CDK code examples, patterns, L3 constructs, sample implementations

Use for:

  • Working code: "Lambda function CDK Python example"

  • Patterns: "API Gateway Lambda CDK pattern"

  • Sample apps: "Serverless application CDK TypeScript"

  • L3 constructs: "ECS service construct"

Include language: Python, TypeScript, Java, C#, Go

cloudformation

For: CloudFormation templates, concepts, SAM patterns

Use for:

  • "CloudFormation StackSets"

  • "DynamoDB table template"

  • "SAM API Gateway Lambda"

  • "CloudFormation template examples"

strands_docs

For: Strands Agents API reference, integrations, model providers, session managers, tools, examples, user-guide

Use for:

  • "Strands Agents Python SDK example"

  • "Strands Agents AWS integration"

  • "Strands Agents community contributions"

  • "Strands Agents usage examples"

  • "Strands Agents usage guide"

general

For: Architecture, best practices, tutorials, blog posts, design patterns

Use for:

  • Architecture patterns: "Serverless architecture AWS"

  • Best practices: "S3 security best practices"

  • Design guidance: "Multi-region architecture"

  • Getting started: "Building data lakes on AWS"

  • Tutorials and blog posts

Common mistake: Not using this for AWS conceptual and architectural questions. Always search for AWS best practices and patterns!

Don't use general knowledge for AWS topics—search instead!

agent_skills

For: Discovering agent skills — domain-specific expertise packages for AWS workflows

Use for:

  • Complex tasks that benefit from guided workflows: "deploy a serverless application"

  • Troubleshooting scenarios: "debug Lambda cold starts", "resolve ECS task failures"

  • Security and compliance: "secure S3 buckets", "review IAM policies for least privilege"

  • Architecture and optimization: "optimize API Gateway latency", "design multi-region architecture"

  • When you need domain expertise beyond what documentation provides

Skills go beyond documentation — they provide workflows, decision frameworks, best practices, and may include embedded procedures for critical sub-tasks.

Important: This topic is meant for discovery. Once you identify the skill you need, use retrieve_skill tool with the skill_name to load the full skill and its reference materials.

Note: If combined with other topics, skills will be mixed into the documentation results. Use agent_skills alone for a clean skill-only listing.

Search Best Practices

Be specific with service names:

Good examples:

"S3 bucket versioning configuration"
"Lambda environment variables Python SDK"
"DynamoDB GSI query patterns"

Bad examples:

"versioning" (too vague)
"environment variables" (missing context)

Include framework/language:

"Amplify authentication React"
"CDK Lambda function TypeScript"
"boto3 S3 client Python"

Use exact error messages:

"AccessDenied error S3 GetObject"
"InvalidParameterValue Lambda environment"

Add temporal context for new features:

"Lambda new features 2024"
"recent S3 announcements"

If the first search does not return results that directly answer the question, refine your query and search again with different terms, a more specific phrase, or a different topic. Try conceptual/architectural topics (general, blogs) if reference docs are too narrow.

After searching, use read_documentation on the top-ranked URLs to verify and complete your answer.

Multiple Topic Selection

You can search multiple topics simultaneously for comprehensive results:

# For a query about Lambda errors and new features:
topics=["troubleshooting", "current_awareness"]

# For CDK examples and API reference:
topics=["cdk_constructs", "cdk_docs"]

# For Amplify and general AWS architecture:
topics=["amplify_docs", "general"]

# For actionable tasks:
topics=["agent_skills"]

Response Format

Results include:

  • rank_order: Relevance score (lower = more relevant)

  • url: Direct documentation link — use with read_documentation to get the full page content

  • title: Page title

  • context: Partial excerpt only — not the complete documentation. After reviewing results, call read_documentation on the most relevant URLs before answering. Do not answer based on the context excerpt alone.

Parameters

search_phrase: str         # Required - your search query
topics: List[str]          # Optional - up to 3 topics. Defaults to ["general"]
limit: int = 5             # Optional - max results per topic

Remember: When in doubt about AWS, always search. This tool provides the most current, accurate AWS information. But search is only step 1 — always read the full documentation to give complete answers.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return
topicsNoList of documentation topics to search. Available topics: reference_documentation, current_awareness, troubleshooting, amplify_docs, cdk_docs, cdk_constructs, cloudformation, agent_skills, strands_docs, general. Can specify multiple topics, up-to 3, to search across them. Use 'general' only if query doesn't match other topics.
search_phraseYesSearch phrase to use
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate read-only and non-destructive behavior. The description reinforces this by stating it is a search tool that returns excerpts only, not full documentation. It also clarifies that results include context excerpts and that full documentation must be read via read_documentation. No contradiction with annotations.

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 very long but well-structured with sections, tables, and front-loaded key information. While not concise in word count, the structure (headings, tables, examples) makes it navigable. Every part earns its place given the tool's complexity.

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 description is highly complete: it covers the tool's purpose, when to use each topic, how to combine multiple topics, search best practices, response format, and follow-up actions (read_documentation, retrieve_skill). There is no output schema, but the description adequately explains response fields. The tool's integration with sibling tools is fully addressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds significant value beyond schema definitions. It explains default values, available topics with detailed usage examples, and best practices for constructing search phrases. The description also includes a table mapping query types to recommended topics.

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 clearly identifies the tool as an AWS documentation search tool, providing a specific verb ('search') and resource ('AWS documentation'). It distinguishes itself from sibling tools like read_documentation and retrieve_skill, and includes an extensive explanation of when to use it versus general knowledge.

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 provides explicit guidance on when to use the tool (e.g., any AWS service, features, errors) and when to skip (non-AWS, purely conceptual). It also details alternative tools (read_documentation, retrieve_skill) and includes a quick topic selection table and search best practices.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Discussions

No comments yet. Be the first to start the discussion!

Try in Browser

Your Connectors

Sign in to create a connector for this server.

Resources