Skip to main content
Glama
aws-powertools

Powertools MCP Search Server

search_docs

Search AWS Lambda Powertools documentation across Python, TypeScript, Java, and .NET runtimes to find details on features like Logger, Tracer, Metrics, and Idempotency using text queries.

Instructions

Perform a search of the Powertools for AWS Lambda documentation index to find web page references online. Great for finding more details on Powertools features and functions using text search. Try searching for features like 'Logger', 'Tracer', 'Metrics', 'Idempotency', 'batchProcessor', etc. Powertools is available for the following runtimes: python, typescript, java, dotnet. If a specific version is not mentioned the search service will use the latest documentation.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runtimeYes
searchYes
versionNo

Implementation Reference

  • The main handler function 'tool' for the 'search_docs' MCP tool. Fetches search index from Powertools docs, builds Lunr index, searches for query, filters by confidence threshold, returns list of relevant doc pages with title, url, score.
    const tool = async (props: ToolProps): Promise<CallToolResult> => {
      const { search, runtime, version } = props;
      logger.appendKeys({ tool: 'searchDocs' });
      logger.appendKeys({ search, runtime, version });
    
      const urlParts =
        runtime === 'python' || runtime === 'typescript' || runtime === 'java'
          ? [runtime, version]
          : [runtime];
      const baseUrl = `${POWERTOOLS_BASE_URL}/${urlParts.join('/')}`;
      const url = new URL(baseUrl);
      const urlSuffix = '/search/search_index.json';
      url.pathname = `${url.pathname}${urlSuffix}`;
    
      let searchIndexContent: {
        docs: { location: string; title: string; text: string }[];
      };
      try {
        const content = await fetchWithCache({
          url,
          contentType: 'application/json',
        });
        searchIndexContent = JSON.parse(content);
        if (
          isNullOrUndefined(searchIndexContent.docs) ||
          !Array.isArray(searchIndexContent.docs)
        ) {
          throw new Error(
            `Invalid search index format for ${runtime} ${version}: missing 'docs' property`
          );
        }
      } catch (error) {
        logger.error('Failed to fetch search index', {
          error: (error as Error).message,
        });
        return buildResponse({
          content: `Failed to fetch search index for ${runtime} ${version}: ${(error as Error).message}`,
          isError: true,
        });
      }
    
      // TODO: consume built/exported search index - #79
      const index = lunr(function () {
        this.ref('location');
        this.field('title', { boost: 1000 });
        this.field('text', { boost: 1 });
        this.field('tags', { boost: 1000000 });
    
        for (const doc of searchIndexContent.docs) {
          if (!doc.location || !doc.title || !doc.text) continue;
    
          this.add({
            location: doc.location,
            title: doc.title,
            text: doc.text,
          });
        }
      });
    
      const results = [];
      for (const result of index.search(search)) {
        if (result.score < SEARCH_CONFIDENCE_THRESHOLD) break; // Results are sorted by score, so we can stop early
        results.push({
          title: result.ref,
          url: `${baseUrl}/${result.ref}`,
          score: result.score,
        });
      }
    
      logger.debug(
        `Search results with confidence >= ${SEARCH_CONFIDENCE_THRESHOLD} found: ${results.length}`
      );
    
      return buildResponse({
        content: results,
      });
    };
  • Zod schema defining and validating the input parameters for the search_docs tool: search (required string), runtime (enum), version (optional string, default 'latest').
    const schema = {
      search: z
        .string()
        .transform((val) => val.toLowerCase().trim())
        .describe('what to search for'),
      runtime: z
        .enum(runtimes)
        .describe('the Powertools for AWS runtime to search the documentation for'),
      version: z
        .string()
        .transform((val) => val.toLowerCase().trim())
        .optional()
        .describe('version is always semantic 3 digit in the form x.y.z')
        .default('latest'),
    };
  • src/server.ts:24-28 (registration)
    Registers the 'search_docs' tool on the MCP server using the imported name, description, input schema, and handler function.
      searchDocsName,
      searchDocsDescription,
      searchDocsSchema,
      searchDocs
    );
  • Defines the constant name 'search_docs' and detailed description used for tool registration.
    const name = 'search_docs' as const;
    const description =
      'Search Powertools for AWS Lambda documentation to learn about Serverless best practices. ' +
      "Try searching for features like 'Logger', 'Tracer', 'Metrics', 'Idempotency', 'batchProcessor', event handler, etc. " +
      'Powertools is available for the following runtimes: python, typescript, java, dotnet. ' +
      'When searching, always specify the version of Powertools you are interested in, if unsure, try to read it from the workspace configuration, otherwise use "latest".';
    
    export { name, description };
  • Index file re-exporting name, description, schema, and tool handler for convenient import in server.ts.
    export { description, name } from './constants.ts';
    export { schema } from './schemas.ts';
    export { tool } from './tool.ts';
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the search service defaults to the latest documentation if no version is specified, which adds useful context. However, it doesn't cover other behavioral aspects like rate limits, authentication needs, or what the output looks like (e.g., search results format).

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 front-loaded with the core purpose and efficiently provides examples and runtime details in subsequent sentences. It avoids unnecessary fluff, though the last sentence about version defaults could be integrated more seamlessly. Overall, it's well-structured and concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description covers the basic purpose and some parameter context but lacks details on output format, error handling, or advanced usage scenarios. It's adequate for a simple search tool but has clear gaps in completeness.

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

Parameters2/5

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

The schema description coverage is 0%, so the description must compensate. It explains the 'runtime' parameter by listing supported runtimes (python, typescript, java, dotnet) and the 'version' parameter by noting it defaults to latest if unspecified. However, it doesn't clarify the 'search' parameter beyond examples, leaving its semantics partially undefined.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/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: 'Perform a search of the Powertools for AWS Lambda documentation index to find web page references online.' It specifies the resource (Powertools documentation) and action (search), though it doesn't explicitly differentiate from the sibling 'fetch_doc_page' tool. The description provides helpful examples of search terms, which enhances clarity.

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

Usage Guidelines3/5

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

The description implies usage by suggesting search terms ('Logger', 'Tracer', etc.) and mentioning runtime support, but it doesn't explicitly state when to use this tool versus 'fetch_doc_page' or provide any exclusion criteria. It offers some contextual guidance but lacks clear alternatives or prerequisites.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/aws-powertools/powertools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server