AWS Knowledge
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.
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.
Tool Definition Quality
Average 4.8/5 across 6 of 6 tools scored.
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.
All tools follow a consistent 'aws___<verb_noun>' pattern with underscores (e.g., 'get_regional_availability', 'list_regions'). The naming is predictable and uniform.
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.
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 toolsaws___get_regional_availabilityARead-onlyInspect
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
Pre-deployment Validation
Verify resource availability before deployment
Prevent deployment failures due to regional restrictions
Validate multi-region architecture requirements
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_regionsthen count, or usesearch_documentationQuestions about documentation, announcements, or general service availability dates — use
search_documentationCloudFormation resource coverage questions across all regions — use
search_documentationwith topiccloudformationAny question that asks about availability in general without specifying a known product name, API, or CFN resource type — use
search_documentationinstead, 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.
Product - service and feature (resource_type='product') Format: 'Product' Example filters:
['Latency-Based Routing', 'AWS Amplify', 'AWS Application Auto Scaling']
['PrivateLink Support', 'Amazon Aurora']
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']
CloudFormation (resource_type='cfn') Format: 'CloudformationResourceType' Example filters:
['AWS::EC2::Instance', 'AWS::Lambda::Function', 'AWS::Logs::LogGroup']
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | Target AWS region code (e.g., us-east-1, eu-west-1, ap-southeast-2). | |
| filters | No | Optional 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. | |
| regions | No | One 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_token | No | Pagination token from previous response for retrieving additional results. Only valid for single region queries and no filters. | |
| resource_type | Yes | Type of AWS resource: 'product' (AWS services/features), 'api' (SDK/API operations), or 'cfn' (CloudFormation resource types). |
Tool Definition Quality
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.
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.
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.
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.
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.
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_regionsARead-onlyInspect
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_documentationfor a documented answerQuestions about service or feature availability in specific regions — use
get_regional_availabilityfor known product names, orsearch_documentationfor general coverage questionsAny question that can be answered from AWS documentation — use
search_documentationinstead
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
Infrastructure Planning: Review available regions for global deployment
Region Validation: Verify region codes before using in other operations
Regional Inventory: Get a complete list of AWS's global infrastructure
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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.
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.
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.
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.
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.
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_documentationARead-onlyInspect
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_indexset to the previousend_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
https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html
https://docs.aws.amazon.com/lambda/latest/dg/lambda-invocation.html
https://aws.amazon.com/about-aws/whats-new/2023/02/aws-telco-network-builder/
https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/
https://aws.amazon.com/blogs/developer/make-the-most-of-community-resources-for-aws-sdks-and-tools/
https://ui.docs.amplify.aws/angular/connected-components/authenticator
https://github.com/aws-samples/aws-cdk-examples/blob/main/README.md
https://github.com/awslabs/aws-solutions-constructs/blob/main/README.md
https://constructs.dev/packages/aws-cdk-lib/v/2.229.1?submodule=aws_lambda&lang=typescript
https://github.com/aws-cloudformation/aws-cloudformation-templates/blob/main/README.md
https://strandsagents.com/docs/user-guide/quickstart/overview/index.md
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_urlfield
Handling Long Documents
If the response indicates the document was truncated, you have several options:
Continue Reading: Make another call with
start_indexset to the previousend_index— do this if the answer may be in the remaining contentJump to Section: Use the ToC character positions to jump directly to specific sections
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}]}| Name | Required | Description | Default |
|---|---|---|---|
| requests | No | List of documentation requests, each containing url, max_length (optional), and start_index (optional). |
Tool Definition Quality
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.
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.
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.
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.
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.
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___recommendARead-onlyInspect
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:
Highly Rated: Popular pages within the same AWS service
New: Recently added pages within the same AWS service - useful for finding newly released features
Similar: Pages covering similar topics to the current page
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:
Find any page belong to that service, typically you can try the welcome page
Call this tool with that URL
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)
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the AWS documentation page to get recommendations for |
Tool Definition Quality
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.
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.
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.
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.
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.
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_skillARead-onlyInspect
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
fileparameterDecision 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)
FIRST: Call search_documentation with the user's requirements
THEN: Find the result entry that has a skill_name field
FINALLY: Call this tool with the EXACT skill_name value from that result — copy it verbatim
Working with Skills
When you retrieve a skill:
Read the SKILL.md overview to understand the domain and scope
Follow the workflows and guidance in the skill body
When the skill references additional files (e.g.,
[architecture](references/architecture.md)), retrieve them using this same tool with thefileparameterApply 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.
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Optional 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_name | Yes | Exact skill name from the skill_name field in search_documentation results (no modifications) |
Tool Definition Quality
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.
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.
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.
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.
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.
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_documentationARead-onlyInspect
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_skilltool with theskill_nameOnce 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 |
| "S3 PutObject boto3", "Lambda invoke API" |
New features, releases |
| "Lambda new features 2024", "what's new in ECS" |
Errors, debugging |
| "AccessDenied S3", "Lambda timeout error" |
Amplify apps |
| "Amplify Auth React", "Amplify Storage Flutter" |
CDK concepts, APIs, CLI |
| "CDK stack props Python", "cdk deploy command" |
CDK code samples, patterns |
| "serverless API CDK", "Lambda function example TypeScript" |
CloudFormation templates |
| "DynamoDB CloudFormation", "StackSets template" |
Architecture, blogs, guides |
| "Lambda best practices", "S3 architecture patterns" |
Strands Agents |
| "Strands Agents Python structured output", "Strands Agents AWS CDK EC2 Deployment Example" |
Domain expertise, workflows, guided procedures |
| "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 withread_documentationto get the full page contenttitle: Page titlecontext: Partial excerpt only — not the complete documentation. After reviewing results, callread_documentationon 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 topicRemember: 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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| topics | No | List 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_phrase | Yes | Search phrase to use |
Tool Definition Quality
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.
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.
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.
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.
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.
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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!