Skip to main content
Glama
r3-yamauchi

Amazon Bedrock Knowledge Base MCP Server

by r3-yamauchi

list_knowledge_bases

Retrieve all available Amazon Bedrock Knowledge Bases to manage RAG data sources, document ingestion, and query configurations.

Instructions

すべてのAmazon Bedrock Knowledge Baseの一覧を取得します。

Returns: KnowledgeBaseListResponseDict: Knowledge Base一覧 - count: Knowledge Baseの数 - knowledge_bases: Knowledge Baseの詳細情報のリスト

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYes
knowledge_basesYes

Implementation Reference

  • Tool registration and handler implementation for listing knowledge bases.
    @mcp.tool()  # MCPツールとして公開
    @handle_errors  # エラーハンドリングデコレータを適用
    def list_knowledge_bases() -> KnowledgeBaseListResponseDict:
        """
        すべてのAmazon Bedrock Knowledge Baseの一覧を取得します。
        
        Returns:
            KnowledgeBaseListResponseDict: Knowledge Base一覧
                - count: Knowledge Baseの数
                - knowledge_bases: Knowledge Baseの詳細情報のリスト
        """
        # BedrockクライアントからすべてのKnowledge Baseを取得
        # ページネーションが自動的に処理され、すべてのKnowledge Baseが取得されます
        knowledge_bases = bedrock_client.list_knowledge_bases()
        
        # レスポンスを整形して返す
        # count: Knowledge Baseの総数
        # knowledge_bases: Knowledge Baseの詳細情報のリスト
        return {
            "count": len(knowledge_bases),
            "knowledge_bases": knowledge_bases,
        }
  • Implementation of the list_knowledge_bases logic using boto3 paginator.
    def list_knowledge_bases(self) -> List[Dict[str, Any]]:
        """
        すべてのKnowledge Baseの一覧を取得します。
        
        ページネーションを使用して、すべてのKnowledge Baseを取得します。
        
        Returns:
            List[Dict[str, Any]]: Knowledge Baseの詳細情報のリスト
                各要素には以下の情報が含まれます:
                - knowledgeBaseId: Knowledge BaseのID
                - name: Knowledge Baseの名前
                - status: Knowledge Baseのステータス
                - description: Knowledge Baseの説明(オプション)
                - updatedAt: 最終更新日時
        
        Raises:
            ClientError: AWS API呼び出しが失敗した場合
        """
        try:
            knowledge_bases = []
            
            # ページネーターを取得(複数ページの結果を自動的に処理)
            # AWS APIはページネーションを使用して結果を返すため、
            # paginatorを使用することで、すべてのページを自動的に処理できます
            paginator = self.bedrock_agent.get_paginator("list_knowledge_bases")
            
            # すべてのページをループして結果を収集
            # paginate()メソッドは、すべてのページを順番に返すイテレータを返します
            # 各ページには、knowledgeBaseSummariesというキーにKnowledge Baseのサマリー情報が含まれます
            for page in paginator.paginate():
                # 各ページからKnowledge Baseサマリーを取得してリストに追加
                # ページにknowledgeBaseSummariesキーがない場合(空のページなど)は空リストを返します
                knowledge_bases.extend(page.get("knowledgeBaseSummaries", []))
            
            # 取得したKnowledge Baseの数をログに記録
            logger.info(f"Retrieved {len(knowledge_bases)} knowledge bases")
            return knowledge_bases
            
        except ClientError as e:
            logger.error(f"Error listing knowledge bases: {e}")
            raise
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states what the tool does and the return structure, but doesn't cover important aspects like whether it's read-only, if there are rate limits, authentication requirements, pagination behavior, or error handling. For a tool with zero annotation coverage, this is a significant gap in transparency.

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 appropriately sized and front-loaded, with the main purpose stated first in a clear sentence. The return information is provided concisely. However, the Japanese text might add slight complexity for non-Japanese agents, and it could be slightly more structured by separating purpose and returns more distinctly.

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 low complexity (0 parameters) and the presence of an output schema (which describes the return structure), the description is somewhat complete. It states the purpose and hints at the return format. However, without annotations and with missing behavioral details (e.g., safety, performance), it doesn't fully compensate for the lack of structured context, making it adequate but with clear gaps.

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 has 0 parameters with 100% coverage, so the schema fully documents the lack of parameters. The description doesn't need to add parameter information, and it correctly doesn't mention any parameters. This meets the baseline for tools with no parameters, as it doesn't mislead about inputs.

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 as 'すべてのAmazon Bedrock Knowledge Baseの一覧を取得します' (get a list of all Amazon Bedrock Knowledge Bases), which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_knowledge_base' (which retrieves details of a specific knowledge base) or 'list_data_sources' (which lists data sources rather than knowledge bases), missing full sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing a full list versus a specific knowledge base (use 'get_knowledge_base'), or how it relates to other listing tools like 'list_data_sources'. There's no context on prerequisites or exclusions, leaving usage unclear.

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

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/r3-yamauchi/bedrock-kb-mcp-server'

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