Strands Agents MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_docsA | Search the curated documentation catalog. The catalog contains Strands Agents user guides, API reference pages, and examples. Ranking starts from document titles and also considers page content once a page has been fetched (hydrated), so both title-like keywords ("bedrock model", "MCP tools") and body terms ("guardrail", "temperature") work. The top results are fetched on demand to hydrate the index and provide content snippets. Call fetch_doc with a result URL to read the page or one of its sections. Args: query: Search query string (e.g., "bedrock model", "tell me about a2a", "how to use MCP tools") k: Maximum number of results to return (default: 5) Returns: List of dictionaries containing: - url: Document URL - title: Display title - score: Unbounded weighted TF-IDF score. Higher is better within this result set; do not interpret it as a probability or compare it across different queries. - snippet: Contextual content preview |
| fetch_docA | Read documentation pages with smart sectioning for token efficiency. Two modes of operation:
For small documents (under ~8KB), the full content is returned directly regardless of mode, since sectioning would add overhead without benefit. Recommended workflow:
Args: uri: Document URL (must be under https://strandsagents.com/). If empty, returns a catalog of all available document URLs with titles. section: Section ID from the TOC (e.g., "3" or "3.2"). Omit to get the table of contents. Returns: When section is omitted (TOC mode): - url, title: Document metadata - preamble: Introductory text between page title and first section - sections: List of sections with id, level, title, summary, children |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: search_docs discovers relevant documentation URLs, while fetch_doc reads a specific page or section. The descriptions explicitly document the recommended search-then-fetch workflow, leaving little ambiguity.
Both tool names follow a consistent verb_noun snake_case pattern: search_docs and fetch_doc. The slight singular/plural difference is natural and does not create confusion.
Two tools is slightly below the typical 3-15 range, but for a focused documentation search-and-read server this is a clean, well-scoped surface. Each tool clearly earns its place.
The server covers the full retrieval lifecycle: search for documents, list catalog URLs, inspect document structure via TOC, and read specific sections or full small documents. No obvious documentation-access gaps remain.