Skip to main content
Glama
YawLabs

@yawlabs/aws-mcp

Official
by YawLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aws_docs_search

Read-onlyIdempotent

Search live AWS documentation to find the right doc page for new services, changed APIs, or exact parameter names. Flags weak matches so you re-query with different wording.

Instructions

Search the live AWS documentation (the same backend that powers the docs.aws.amazon.com search box). Use this to discover the right doc page for a service, API, or concept the model may not know about -- new services, recently changed APIs, exact parameter names. Returns ranked results as {title, url, summary, excerpt}. IMPORTANT: that backend always returns a full page of fuzzy matches and has no way to answer 'no good match' -- a nonsense query still comes back with ten confident-looking hits. So each result also carries lexicalMatch ({overlap 0-1, matchedTerms, unmatchedTerms}), computed locally by this server: literal word overlap between your query's terms and the result's title/summary/excerpt, NOT a backend score and NOT semantic ranking. The response adds queryTerms, termsMatchedNowhere, bestLexicalOverlap, and lowRelevance: true when the best result matched at or under half your terms OR any term appears in no result at all (a term matching nothing anywhere is the clearest sign the backend had nothing -- one incidental hit on a common word can otherwise carry the average) -- that means the backend had nothing close for those terms, NOT that the search failed, so re-query with different wording rather than citing a weak hit. Follow up with aws_docs_read on a result's url to get the full page as markdown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return (1-50). Default 10.
queryYesSearch phrase, e.g. 'S3 bucket naming rules', 'Lambda environment variables', 'DynamoDB GSI'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.2

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, the description discloses the backend's fuzzy-match flaw (always returns confident-looking hits even for nonsense queries), the locally computed lexicalMatch metric, and the lowRelevance flag semantics. It warns the agent to re-query rather than citing weak hits, which is critical behavioral context. 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 long but every clause carries necessary caveats for a search tool with misleading backend behavior. It front-loads the main purpose and then layers the caveat and its interpretation; a minor redundancy in explaining 'no good match' slightly reduces conciseness.

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?

No output schema exists, so the description carries the burden of explaining return shape and it does: ranked {title, url, summary, excerpt}, plus lexicalMatch and lowRelevance fields with exact meaning. It also gives a concrete follow-up action and enough caveat detail to prevent misuse.

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

Parameters3/5

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

Input schema already covers both parameters with descriptions and examples, so baseline is 3. The description adds the notion of query terms being used for lexical overlap, but it does not need to explain limit, which the schema documents fully.

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?

Description opens with a specific verb-resource pair ('Search the live AWS documentation') and explicitly states the use case: 'discover the right doc page for a service, API, or concept the model may not know about'. It distinguishes itself from the sibling aws_docs_read by framing search as the discovery step and read as the follow-up.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit conditions for use: discovering new services, recently changed APIs, and exact parameter names. It identifies the logical next tool (aws_docs_read) but does not explicitly state when not to use this tool, stopping short of a full when/when-not contrast.

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

Deploy Server

Other Tools