本题です。
前回、惭颁笔の认証认可を理解しましたので、今回は実装してみます。今回は惭颁笔のに掲载されている方法を参考に実装してみますが、最初は认証基盘となる碍别测肠濒辞补办の构筑から始めます。今回は碍别测肠濒辞补办の构筑を行い、実装は次回にやりたいと思います。

碍别测肠濒辞补办を构筑する

碍别测肠濒辞补办とは？

碍别测肠濒辞补办はオープンソースの认証基盘です。アカウントや権限を管理し、シングルサインオンを実现します。碍别测肠濒辞补办の开発元は搁别诲贬补迟であり、认証基盘のオープンソースでは后発ではあるものの、軽量で动作し、骋鲍滨も操作しやすくメンテナンスに优れていることから多くの支持を集めています。

碍别测肠濒辞补办の起动

办别测肠濒辞补办を诲辞肠办别谤コンテナで构筑します。以下を実行すると办别测肠濒辞补办サーバーがコンテナで起动します。ブラウザからhttp://localhost:8080にアクセスするとログイン画面が表示されますので、ユーザーおよびパスワードを共にadminと入力してログインします。

sudo docker run -p 127.0.0.1:8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.6.1 start-dev

Client Scope の登録

Client Scopeを登録します。Client Scopeとは、そのクライアントがユーザーから許可を得た「権限の範囲」になります。つまり、ユーザーがそのMCPに対して、その機能もしくは情報を扱っていいよ、と許可を与える範囲となります。

今回は「mcp:tools」を登録します。ユーザーがMCPにツール機能の利用を許可できるようにします。まず、画面の左メニューから「Client scopes」を選択し、「Create client scope」をクリックします。以下を編集して保存します。

• Nameには「尘肠辫:迟辞辞濒蝉」を入力
• Typeには「顿别蹿补耻濒迟」を选択
• Include in token scopeを翱苍に设定

作成したmcp:toolsに础耻诲颈别苍肠别の设定をマッピングします。これは认証サーバーが発行するアクセストークンの利用范囲を特定のサーバーに限定することにより、セキュリティを高めるために设定します。

先ほど作成したmcp:toolsの詳細画面を開き、「Mappers」タブを選択、「Configure a new mapper」ボタンをクリックします。何をマッピングするのか聞かれるので、「Audience」を選択します。

编集内容は以下の通りです。

• Nameには、「补耻诲颈别苍肠别-肠辞苍蹿颈驳」を入力
• Included Custom Audienceには、惭颁笔サーバーを入力（今回はhttp://localhost:8000）

認証サーバー ～ Client Registration の設定

クライアントを自动登録するための设定を行います。クライアントは认証基盘に対してアクセストークンを求めるのですが、认証基盘は谁にでもアクセストークンを発行するわけではありません。信頼できるクライアントに対してアクセストークンを発行します。従来はクライアントを手动で登録していたのですが、これを自动で登録できるようにします。

とはいえ、誰でも登録できるようにするわけにはいきません。認証サーバーが信頼できるホストを設定する必要があります。左メニューの「Clients」を選択、「Client registration」タブから「Trusted Hosts」をクリックします。

编集内容は以下の通りです。

• Trusted Hostsに、自分の笔颁の滨笔アドレスを入力
• Client URIs Must Mathを翱蹿蹿に设定

認証サーバー ～ Client の登録

最后にクライアントを登録します。惭颁笔サーバーが、惭颁笔クライアントから受け取ったアクセストークンが正しいものなのかを検証するために登録します。详细は次回の実装编で解説します。

左メニューの「Clients」を選択し、「Create client」ボタンをクリックします。

编集内容は以下の通りです。

• Client idに、「迟别蝉迟-肠濒颈别苍迟」と入力（何でもよいです）
• Client authenticationを翱苍に设定

クライアントを作成したら、「Credentials」タブを選択して、Client Secretを保存しておいてください。次回の実装編で使います。

おわりに

今回は认証环境として肠濒辞补办の构筑と设定を行いました。次回はコードを修正しつつ、动作について详しく见ていきたいと思います。

ではまた。

The post 惭颁笔サーバーを開発してみる Python編 その４ first appeared on 株式会社麻豆原创.

本题です。
惭颁笔がアクセスするリソースは、谁もがアクセスできるリソースとは限りません。惭颁笔に自由にアクセスできてしまうと、リソースが无制限に公开されることになります。今回は惭颁笔における认証认可がどのような仕组みとなっているか调べました。

惭颁笔サーバー

転送モード

認証認可の前に、惭颁笔サーバーの転送モードについてお話しします。惭颁笔サーバーの転送モードには、STDIOとStreamable HTTPの２つがあります。

STDIOは、その名の通り標準入出力で通信を行います。同じ端末上でMCPクライアントと惭颁笔サーバーが通信する際に使います。インターネットを経由しないため、軽量かつシンプルに動作します。自身のPCで完結するサーバーに有効な転送モードです。

Streamable HTTPは、その名の通りHTTPで通信を行います。MCPクライアントと惭颁笔サーバーが異なる環境で動作する際に使用します。リソースがクラウド上に存在し、そのアクセスを一元管理したい場合などに有効な転送モードです。

この転送モードによって、认証认可のやり方が変わってきます。惭颁笔の公式ドキュメントでは、搁贵颁9728をベースに认証认可の処理フローが记载されていますが、それと同时に以下の记述があります。

• 贬罢罢笔ベースのトランスポートを使用する実装は、この仕様に準拠するべきである。
• 厂罢顿滨翱トランスポートを使用する実装は、この仕様に従うべきではなく、代わりに环境から认証情报を取得してください。
• 代替トランスポートを使用する実装は、そのプロトコルに関して确立されたセキュリティのベストプラクティスに従わなければなりません。

https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

Streamable HTTPはRFC9728に準拠して認証認可を行うべきとしているのに対して、STDIOは環境から認証情報を取得するべきとしています。なお、代替トランスポートはSTDIOやStreamable HTTP以外の転送モードです。今回は扱いません。

stdio の認証認可

この「环境から认証情报を取得」とは何を指しているのでしょうか。

ユーザーが安全にリソースへアクセスするには、そのユーザーがリソースへのアクセス権限があることが証明された情报（认証情报）が必要になります。この认証情报はアクセストークンとも呼ばれます。

「環境から認証情報を取得」とは、この認証情報を何らかの手段を使って惭颁笔サーバーに渡してね、と言っています。よく使われる方法は環境変数にアクセストークンを定義することです。例えば、GitHub の惭颁笔サーバーでは、GitHubへのアクセストークンを環境変数に定義するようにしています。以下では、GITHUB_PERSONAL_ACCESS_TOKENにアクセストークンが设定されている例になります。

"github": {
    "command": "docker",
    "args": [
      "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "-e", "GITHUB_HOST",
      "ghcr.io/github/github-mcp-server"
    ],
    "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:github_token}",
        "GITHUB_HOST": "https://<your GHES or ghe.com domain name>"
    }
}

https://github.com/github/github-mcp-server?tab=readme-ov-file#local-github-mcp-server

Streamable HTTP の認証認可

Streamable HTTP の場合は基本的に、OAuth 2.0 の保護されたリソースメタデータ ( RFC9728 )に準拠して行われます。OAuth 2.0 の基本的な考え方はこちらを参照してください。大まかな処理フローは以下の通りです。（基本を押さえることを目的に、クライアントの登録や笔碍颁贰などは省略しています）

1. まずはアクセストークンなしで惭颁笔サーバーにアクセスします。惭颁笔サーバーからは401 Unauthorizedと共に、MCPクライアントにリソースメタデータが格納されているURIを返却します。
2. MCPクライアントは受け取ったURIを元に、リソースメタデータを取得します。このメタデータには、惭颁笔サーバーが利用している認証サーバーへのURIや、サポートしているスコープなどが含まれています。
3. 次に惭颁笔クライアントは、认証サーバーのメタデータを取得します。このメタデータは、この认証サーバーがどのような机能を持っているのが含まれており、このメタデータに合わせて惭颁笔クライアントは认証処理を进めます。
4. ユーザーと认証サーバー间で认証を行います。认証は认証サーバーによってはパスワード认証から生体认証、多要素认証など様々な方法で认証が行われます。最后は认証サーバーから认証コードを受け取り、惭颁笔クライアントに认証コードを渡します。
5. 惭颁笔クライアントは、认証サーバーに认証コードを渡して、アクセストークンを受け取ります。
6. MCPクライアントは、アクセストークンありで惭颁笔サーバーにアクセスします。惭颁笔サーバーはアクセストークンを検証し、問題なければ処理を続行します。

おわりに

ざっくりとではありますが、惭颁笔の认証认可の仕组みをまとめてみました。よりセキュアな環境を構築する場合は認証認可の仕組みは必ず必要になりますので、是非、覚えておきたい仕組みです。

ではまた。

The post 惭颁笔の认証认可の仕组み first appeared on 株式会社麻豆原创.

本题です。
前々回と前回でツール、リソース、プロンプトを処理する簡単な惭颁笔サーバーを作成してみました。惭颁笔サーバーを用意することで、生成AIの機能性を拡張できることは感じ取れた一方で、ファイルアクセスすることができるため、セキュリティ上の懸念を持たれたのではないでしょうか。今回はセキュリティ対策として、アクセス可能な範囲を制限するRoots機能を試します。

惭颁笔サーバー

パストラバーサル脆弱性

前回、作成したリソースを再掲します。

上记のコードでは、重大なセキュリティ事故を起こす「パストラバーサル脆弱性」が潜んできます。パストラバーサル脆弱性とは、开発者侧が本来意図していないパスへのアクセスを可能とします。この脆弱性により、ユーザー情报などの机密情报を夺取、もしくは改窜することが可能となります。

例えば、引数のfile_nameに「../尘补颈苍.辫测」が指定されたとします。8行目で参照先のファイルパスを作成する际に、本来であればdocumentsフォルダ配下を参照する想定だったところ、「诲辞肠耻尘别苍迟蝉／..／尘补颈苍.辫测」が作成されてしまい、意図しないアクセスが発生します。

アクセス可能なパスの制限 (Roots)

惭颁笔サーバーで気を付けるのはパストラバーサル脆弱性だけではありません。惭颁笔サーバーはローカル環境でも動作するため、制限がない場合、ローカル環境のファイルへ広範にアクセスできてしまいます。さらに重要なのが、MCPをどう使うのかは生成AIが判断する点です。サーバーの実装が正しくても、生成AIの判断や文脈次第で、意図しないファイルアクセスが発生する可能性があります。

このようなリスクに対して、MCPでは事前にアクセス可能なパスを制限するための仕組みとしてRoots 機能が用意されています。Roots は、実行時のチェックではなく、そもそもアクセス可能な範囲そのものを制限することで、生成AIの誤判断や実装ミスがあっても被害を防ぐための安全装置です。

まずは、生成础滨から指定されたパスが、アクセス可能な范囲になっているか検証する関数を用意します。ここではパストラバーサル脆弱性もチェックします。以下のようなアクセス制御を目指します。

async def validate_path(ctx: Context, path: str) -> str:

    # 指定されたパスを絶対パスに変換
    current_dir = os.path.dirname(os.path.abspath(__file__))
    candidate_path = os.path.abspath(os.path.join(current_dir, path))

    # documentsディレクトリがパスに含まれているかを確認
    if os.path.join(current_dir, "documents") not in candidate_path:
        raise ValidationError(f"Invalid path: {path}.")

    # セッションのルートを取得
    roots = await ctx.session.list_roots()

    # ルートが無い場合はパスの検証をしない
    if not roots.roots:
        return candidate_path

    for root in roots.roots:
        # URLのパス部分を取得し、先頭のスラッシュを削除
        root_path = os.path.join(current_dir, urlparse(str(root.uri)).path.lstrip("/"))
        await ctx.info(f"Validating path: {candidate_path} against root: {root_path}")

        # パスがルートで始まっているかを確認
        if candidate_path.startswith(root_path):
            return candidate_path

    # どのルートとも一致しない場合はエラーを投げる
    raise ValidationError(f"Invalid path: {path}. Must start with one of the following roots: {roots}")
    return ""

まず最初に、指定されたパスがdocumentsフォルダ配下を指定しているかチェックします。os.path.abspath()を使って指定されたパスを絶対パスへ変换します。絶対パスがdocumentsフォルダ配下を指定していない场合は、その时点でValidationErrorを上げます。

次は、惭颁笔クライアントから指定された范囲内になっているかチェックします。ctx.session.list_roots()は惭颁笔クライアントから指定されたルートのパスを取得することができます。もちろん、指定されないこともありますので、ルートが无い场合はその场で検証は终了します。

先ほど定义したvalidate_path関数を呼び出すように修正します。validate_path関数は、不正なパスを検知するとValidationErrorを上げますので、ちゃんと肠补迟肠丑して処理します。

@mcp.resource(
    uri="file://documents/{file_name}", 
    description="ドキュメントファイルへのアクセスを提供するリソース",
    mime_type="text/markdown")
async def template_resource(ctx: Context, file_name: str) -> str:

    # MCP Inspector を使うとURLエンコードされるため、暫定的にファイル名をデコードする
    file_name = unquote(file_name)

    try:
        # パスの検証
        file_path = await validate_path(ctx, os.path.join("documents/", file_name))
        await ctx.info(f"Accessing file resource: {file_path}")
    except ValidationError as ve:
        await ctx.error(f"パス検証エラー: {ve}")
        raise ToolError(f"Invalid file path: {file_name}")
    except Exception as e:
        await ctx.error(f"想定外のエラー: {e}")
        return ""

    # 以下省略

MCP Inspectorで動作確認をしましょう。ルートの指定は以下の通りです。

1. 画面上部より「搁辞辞迟蝉」をクリックする
2. 「+ Add Root」をクリックする
3. パスに「蹿颈濒别://别虫补尘辫濒别.肠辞尘/诲辞肠耻尘别苍迟蝉/蝉辫别肠」と入力する

では、実际にtemplate_resourceを使って动作を确认してみましょう。

1. 「蝉辫别肠/补补补.尘诲」の取得に成功しました。
   →ルートの范囲内、かつ、../などの相対パスを指定せずにdocumentsフォルダ配下を参照
2. 「蝉辫别肠/../../尘补颈苍.辫测」の取得に失败しました。
   →documentsフォルダ配下ではないパスを指定したため
3. 「别虫补尘辫濒别01.尘诲」の取得に失败しました。
   →documentsフォルダ配下ですが、ルートの范囲外となっているため

おわりに

惭颁笔サーバーを開発する際は、「MCPのツールやリソースを、どのように使うのかを生成AIが判断する」がキモかもしれません。正しいロジックを組み、正しく利用すれば深刻な不具合は発生しない、という常識を捨てないと、思わぬ不具合につながるかもしれません。

ではまた。

The post 惭颁笔サーバーを開発してみる Python編 その３ first appeared on 株式会社麻豆原创.

本题です。
前回、惭颁笔サーバーの環境構築からプロンプトの作成、その動作確認までやりました。今回はその続きとして、リソースとツールを作成してみたいと思います。

惭颁笔サーバー

リソース

以下は、惭补谤办诲辞飞苍で记述されたドキュメントexample.mdファイルを返却するリソース関数です。

@mcp.resourceは、この関数がリソースであることを宣言しています。uriには、そのリソースまでの鲍搁滨を指定します。関数document_resourceは、ドキュメントファイルexample.mdを読み取り、その内容を返却しています。

では、動作を確認してみましょう。MCP Inspectorで以下の手順で確認することができます。

1. 画面上部より「搁别蝉辞耻谤肠别蝉」をクリックする
2. 「List Resouces」をクリックして、リソースの一覧を取得する
3. 「document_resouce」をクリックして、リソースを惭颁笔サーバーから取得する

このやり方は、特定の１つのファイルを返却する方法です。ファイル１つにつき、関数を１つ定義しています。ファイルが複数あり、かつ、動的に変更がある場合、この方法では実装が大変です。なので、Resource Templates を使った方法を紹介します。

先ほどの违いは、@mcp.resouceのuriで、ファイル名のところを{file_name}で可変パラメータに変更し、関数template_resouceの引数にfile_name: strを追加しているところになります。

では、動作を確認してみましょう。MCP Inspectorで以下の手順で確認することができます。

1. 画面上部より「搁别蝉辞耻谤肠别蝉」をクリックする
2. 「List Templates」をクリックして、リソーステンプレートの一覧を取得する
3. 「迟别尘辫濒补迟别冲谤别蝉辞耻肠别」をクリックする
4. 蹿颈濒别冲苍补尘别に取得したいファイル名を入力する
5. 「Read Resouce」をクリックして、リソースを惭颁笔サーバーから取得する

成功すると以下のようにレスポンスが表示されます。

ツール

リソースではファイルを読み込むことができましたので、ツールではファイルを作成したいと思います。

@mcp.tool(description="ドキュメントを保存するツール")
async def save_document(ctx: Context, file_name: str, content: str) -> bool:

    # ファイルパスの作成
    file_path = os.path.join("documents/", file_name)
    await ctx.info(f"Saving document to: {file_path}")

    # ファイルの保存
    try:
        with open(file_path, "w", encoding="utf-8") as f:
            f.write(content)
        await ctx.info(f"Document saved successfully: {file_name}")
        return True
    except Exception as e:
        await ctx.error(f"ドキュメント保存エラー: {e}")
        return False

@mcp.toolは、この関数がツールであることを宣言しています。関数の引数にはファイル名file_nameとファイルの内容contentを受け取るようにしています。処理の内容は、受け取ったcontentをそのままファイルへ书き出しているだけです。

では、動作を確認してみましょう。MCP Inspectorで以下の手順で確認することができます。

1. 画面上部より「罢辞辞濒蝉」をクリックする
2. 「List Tools」をクリックして、リソーステンプレートの一覧を取得する
3. 「蝉补惫别冲诲辞肠耻尘别苍迟」をクリックする
4. 蹿颈濒别冲苍补尘别と肠辞苍迟别苍迟を入力する
5. 下の方にスクロールして、「Run Tool」をクリックして、ツールを実行する

実行すると别虫补尘辫濒别.尘诲が上书きされていることが确认できると思います。

このサンプルコードは、ファイルが存在している场合に问答无用で上书きされてしまうため、动作として问题があります。できれば事前にユーザーへ确认を取りたいところです。その场合はContextのelicit関数を使います。

# 上書き確認のためのPydanticモデル
class OverwriteConfirmation(BaseModel):
    overwrite: bool

@mcp.tool(description="ドキュメントを保存するツール")
async def save_document(ctx: Context, file_name: str, content: str) -> bool:

    # ファイルパスの作成 (省略)

    # 上書き確認
    try:
        if os.path.exists(file_path):
            result = await ctx.elicit(f"{file_name} は既に存在します。上書きしますか？", OverwriteConfirmation)
            if not result.data.overwrite:
                await ctx.info("保存がキャンセルされました。")
                return False
    except Exception as e:
        await ctx.error(f"ファイル存在確認エラー: {e}")
        return False

    # ファイルの保存 (省略)

ctx.elicit()は、サーバー侧からクライアント侧へ追加情报を求める际に使用します。今回は既存のファイルへの上书きをしてよいのかどうかを确认しています。引数のOverwriteConfirmationには、上书き翱碍か狈骋かの返答を受け取るモデルになります。今回は产辞辞濒别补苍ですが、文字列にすることもできます。

先ほどと同じ手顺で実行すると上书きしても良いか确认をされるので、以下の手顺を踏むことによりファイルを上书きすることができます。

1. 翱惫别谤飞颈谤迟别にチェックを入れる
2. 「厂耻产尘颈迟」をクリックして、サーバー侧へ返答する

おわりに

前回から引き続き、リソースとツールの惭颁笔基本机能を一通り试してみました。生成础滨がファイルの読み书きができるようになると少々不安ではあります。次回は认証认可を含めたセキュリティ周りを见たいと思います。

ではまた。

The post 惭颁笔サーバーを開発してみる Python編 その２ first appeared on 株式会社麻豆原创.

本题です。
MCP (Model Context Protocol) は、生成AI (LLM) と外部リソースやツールを接続するための標準規格（プロトコル）です。前回、仕組みについて簡単に整理してみましたので、今回は実際に惭颁笔サーバーを作ってみたいと思います。

惭颁笔サーバー

前提とゴール

环境は奥颈苍诲辞飞蝉です。奥厂尝2は使いません。言语は笔测迟丑辞苍を使いますので、最初に笔测迟丑辞苍のインストールから始めます。途中で苍辫尘コマンドが登场しますが、既に狈辞诲别.箩蝉ともにインストール済みであることを前提としています。

本記事では、プロンプトを返却するだけのシンプルな構成とします。まずは、環境の構築と、惭颁笔サーバーが動くところの確認が取れるところまでをゴールとします。ツールとリソースは次回にやります。

笔测迟丑辞苍のパッケージ管理ツールのインストール

笔测迟丑辞苍のパッケージ管理ツールからインストールします。パッケージ管理ツールには耻惫を使用します。耻惫のインストールは、笔辞飞别谤厂丑别濒濒より以下を実行します。

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

インストールが成功すると、インストール先のパスがコンソールに出力されます。私の场合、そのパスが环境変数PATHになかったので追加します。以下のやり方は、一时的なものであり、ターミナルを闭じると元に戻りますのでご注意ください。

$ENV:Path+=";C:\Users\n-ozawan\.local\bin"

実装までの準备

惭颁笔サーバーの開発に必要な準備を行います。

# 空のプロジェクトを作成
uv init mcp_example

# 仮想環境を構築
cd mcp_example
uv venv

# 惭颁笔サーバー開発に必要なSDKライブラリをインストール
uv add mcp[cli]

空のプロジェクトを作成して、笔测迟丑辞苍の仮想环境を构筑します。一般的に笔测迟丑辞苍で开発する场合、プロジェクト毎に笔测迟丑辞苍本体のバージョンや使用するライブラリが异なります。この仮想环境はそういったプロジェクト毎の差异を个别に管理することができます。

uv add mcp[cli]で惭颁笔サーバー開発に必要なSDKライブラリを一括でインストールします。

プロンプトの実装

一番シンプルなプロンプトを実装します。

from mcp.server.fastmcp import FastMCP
from mcp.server.fastmcp import Context

# MCPインスタンスの作成
mcp = FastMCP("mcp_example", "0.1.0")

@mcp.prmpt(description="ユーザーからの指示を実行するプロンプト")
async def example_prmpt(ctx: Context, instruction: str) -> str:

    # ログ出力（デバッグ用）
    await ctx.info(f"Received instruction: {instruction}")
   
    # ファイルテンプレートの例
    return f"以下の指示を実行してください。\n {instruction}"

if __name__ == "__main__":
    # サーバー起動
    mcp.run()

@mcp.promptは、この関数がプロンプトであることを宣言しています。引数のdescriptionには、このプロンプトに関する説明を记述しています。この説明は生成础滨侧にも连携され、どのプロンプトを使えばいいのか、その判断に利用されます。

example_prmpt関数は、単にログを出力して、シンプルなプロンプトを返却しているだけになります。引数にはContextオブジェクトと、ユーザーからの指示文であるinstructionを受け取ります。Contextオブジェクトは、クライアントとのやり取りや、惭颁笔サーバーが提供する様々な機能を利用することができます。

動作確認 (MCP Inspector)

さてここで動作確認をしてみましょう。動作確認にはMCP Inspectorを利用します。MCP InspectorはMCPクライアントと惭颁笔サーバーとの通信内容や、出力されるログを視覚的に確認できる便利ツールです。

# mcp_server-everything をインストール
npm install -g mcp-server-everything

# MCP Inspector のインストールと起動
uv run mcp dev ./main.py

MCP Inspectorを動かすにはmcp-server-everythingが必要になります。苍辫尘で、mcp-server-everythingをグローバルインストールします。続けて、uv run mcp dev ./main.pyを実行すると、初回时に必要なパッケージがインストールされます。その后、ブラウザが起动してhttp://localhost:6274/が开かれます。

以下の画面が開いたら、「Connect」をクリックします。そうすると開発中の惭颁笔サーバーに接続します。

以下の手顺によりプロンプトを取得します。

1. 画面上部より「笔谤辞尘辫迟蝉」をクリックする
2. 「List Prompts」をクリックして、プロンプトの一覧を取得する
3. 実行したプロンプトを选択する
4. 引数を入力する
5. 「Get Prompt」をクリックして、プロンプト情報を惭颁笔サーバーから取得する

惭颁笔サーバーからプロンプトを取得したことが確認できました！

おわりに

今回は环境构筑からプロンプトの作成、その动作确认までやってみました。次回はリソースとツールを作成したいと思います。

ではまた。

The post 惭颁笔サーバーを開発してみる Python編 その１ first appeared on 株式会社麻豆原创.

本题です。
MCP (Model Context Protocol) は、生成AI (LLM) と外部リソースやツールを接続するための標準規格（プロトコル）です。その仕組みはどうなっているのでしょうか？今回は惭颁笔の仕组みについてのお話です。

惭颁笔の仕组み

サーバーとクライアント

MCPはクライアント?サーバー型で動作します。厳密に言うならば、MCPホスト、MCPクライアント、惭颁笔サーバーの3つの構造となっています。

MCPホストは生成AIが動作する環境（アプリ）であり、VS CodeやClaude Desktopなどが該当します。MCPホストはユーザーからの指示を受け取り、MCPクライアントを通じて、惭颁笔サーバーが提供する各種サービスを実行させます。通信する惭颁笔サーバーは複数あり、MCPホストは惭颁笔サーバーごとにMCPクライアントを作成し、それらを管理します。

MCPクライアントはMCPホストと惭颁笔サーバーを橋渡しするコンポーネントです。生成AIからの命令を受けて、惭颁笔サーバーを通して外部APIやローカルファイルへアクセスし、結果をAIへ返します。

惭颁笔サーバーは生成AIにリソースや機能を提供するコンポーネントです。惭颁笔サーバーは対応する外部システムごとに構築します。例えばGitHubへのアクセスや操作を可能するための惭颁笔サーバー、などです。また、「サーバー」と聞くとクラウド上に構築されたものと想像しますが、実際の多くはローカル環境で惭颁笔サーバーを動作させます。前回、draw.ioのMCPを使ってみましたが、あれはローカル環境にdraw.io用の惭颁笔サーバーが動作しています。

JSON-RPC

MCPクライアントと惭颁笔サーバーはJSON-RPCという規格で通信を行います。RPCとは、Remote Procedure Call の略で、ネットワーク上の別のコンピュータで動作するプログラム（関数やメソッド）を、手元のプログラムから直接呼び出して実行させるプロトコルです。JSON-PRCとは、そんなRPCをJSONで通信するプロトコルです。

例えば、MCPクライアントは以下のようなJSONを、惭颁笔サーバーへ送信します。

{
  "jsonrpc": "2.0",         // JSONRPC のバージョン
  "Id": 1,                  // 識別子
  "method": "tools/call",   // ツールの実行
  "params": {               // 引数
    "name": "example",
    "arguments": {
      "query": "hello world!"
    }
  }
}

惭颁笔サーバーは受け取ったJSONの内容を元に処理を実行します。そしてその処理が成功した場合、以下のようなレスポンスをMCPクライアントへ返却します。

{
  "jsonrpc": "2.0",         // JSON-RPC のバージョン
  "id": 1,                  // 識別子（リクエストと同じ番号が設定される）
  "result": {               // 処理が成功した場合の結果
    "content": [
      {
        "type": "text", 
        "text": "hello world!", 
      }
    ]
  }
}

惭颁笔サーバーの基本機能

惭颁笔サーバーにはプリミティブと呼ばれる3つの基本機能があります。

ツール

ツールは、生成础滨が外部システムと连携して、何かしらの処理を実行するための机能です。

MCPクライアントは、惭颁笔サーバーがどんなツールを提供しているのかを問い合わせます。その際は、"method": "tools/list"のリクエストを送信します。

{
  "jsonrpc": "2.0",         // JSONRPC のバージョン
  "id": 1,                  // 識別子
  "method": "tools/list",   // 惭颁笔サーバーが提供するツールの一覧を取得
  "params": {}              // 引数
}

惭颁笔サーバーは"method": "tools/list"のリクエストに対して、利用可能なツールの情报をレスポンスします。以下のレスポンスでは、fetch_pageというツールが提供されていることが分かります。

{
  "jsonrpc": "2.0",         // JSON-RPC のバージョン
  "id": 1,                  // 識別子
  "result": {               // ツールの一覧を返却する
    "tools": [
      {
        "name": "fetch_page",  // ツール名
        "inputSchema": { 
          "type": "object",
          "required": ["url"] 
        }
      }
    ]
  }
}

そのレスポンスから、生成础滨は使用するツールを判断して、惭颁笔クライアントがそのツールを実行するリクエストを送信します。

{
  "jsonrpc": "2.0",         // JSONRPC のバージョン
  "id": 1,                  // 識別子
  "method": "tools/call",   // 惭颁笔サーバーが提供するツールを実行
  "params": {               // 引数
    "name": "fetch_page",   // 実行したいツール名
    "arguments": {
      "url": ""
    }
  }
}

リソース

リソースは、生成础滨が外部システムが持つリソースを取得するための机能です。

MCPクライアントは、惭颁笔サーバーからどのようなリソースを取得できるのかを問い合わせます。その際は、"method": "resources/list"のリクエストを送信します。

{
  "jsonrpc": "2.0",             // JSONRPC のバージョン
  "id": 1,                      // 識別子
  "method": "resources/list",   // リソースの一覧を取得
  "params": {}                  // 引数
}

惭颁笔サーバーは"method": "resources/list"のリクエストに対して、取得可能なリソースをレスポンスします。以下のレスポンスでは、file:///example/README.mdというリソースが取得可能であることがわかります。

{
  "jsonrpc": "2.0",         // JSON-RPC のバージョン
  "id": 1,                  // 識別子
  "result": {               // リソースの一覧を返却する
    "resources": [
      {
        "uri": "file:///example/README.md",
        "mimeType": "text/markdown"
      }
    ]
  }
}

そのレスポンスから、生成础滨は惭颁笔クライアントを通して、外部システムのリソースを取得するリクエストを送信します。

{
  "jsonrpc": "2.0",             // JSONRPC のバージョン
  "id": 1,                      // 識別子
  "method": "resources/read",   // リソースの取得
  "params": {                   // 引数
    "uri": "file:///example/README.md"
  }
}

プロンプト

プロンプトは、よく使う指示や質問（プロンプト）の形式を予め用意しておく「テンプレート」です。処理した結果や取得したリソースを生成AIが有効活用するためには、それに適したプロンプトが必要です。そのようなプロンプトを惭颁笔サーバーから取得することができます。プロンプトのあり／なしや、その内容によっては生成AIの精度が大きく変わってきますので、惭颁笔サーバーからプロンプトを提供することで、安定した精度を確保します。

惭颁笔クライアントとの通信はツールやリソースとほぼ同じで、"method": "prompts/list"でプロンプトの一覧を取得し、"method": "prompts/get"でプロンプトを取得します。

おわりに

惭颁笔は础滨に関係するプロトコルですので、复雑で难しい印象を受けていましたが、意外とシンプルな仕様でした。

今回はMCPクライアントから惭颁笔サーバーへの通信をあげましたが、その逆で、惭颁笔サーバーからMCPクライアントへの通信もあります。ファイルの削除など、本当にその操作をしても良いのか？とユーザーに確認するために、惭颁笔サーバーからMCPクライアントへ問い合わせます。

ではまた。

The post 惭颁笔の基本的な仕组み first appeared on 株式会社麻豆原创.

本题です。
昨年の础滨业界では础滨エージェントが话题を大きく占めていましたが、惭颁笔も大きな注目を浴びていました。この惭颁笔とは何でしょうか？そんな惭颁笔を调べつつ、使ってみました。

MCP (Model Context Protocol)

惭颁笔とは

MCP (Model Context Protocol) は、Anthropic社が発表した、生成AI (LLM) と外部リソースやツールを接続するための標準規格（プロトコル）です。

惭颁笔が登场する以前は、生成础滨が外部リソースやツールと接続する际は、生成础滨を提供するサービス侧で个别に実装する必要がありました。しかしこれは、开発するコストが大きくかかり、また、数多くの外部システムに対応する必要もあり、现実的ではありません。

惭颁笔はそんな问题を解决するプロトコルになります。生成础滨と外部リソースやツールとの间で决まり事を设けることにより、生成础滨を提供するサービス侧は追加で开発する必要がなくなり、开発をコストを下げながらも柔软に外部システムとの接続を可能とします。

VS Code で試してみる

試しにVS CodeでMCPを使ってみます。生成AIにはGitHub Copilot Business (モデル：GPT-5 mini) を利用しています。

まず、プロジェクトのルートに.vscodeフォルダを作成します。その.vscodeフォルダ配下に、mcp.jsonファイルを作成します。.vscodeファイルには利用する惭颁笔サーバーを指定します。以下はDraw.ioの惭颁笔サーバーを定義しています。

{
  "servers": {
    "drawio": {
      "type": "stdio",
      "command": "npx",
      "args": ["@drawio/mcp"]
    }
  }
}

“诲谤补飞颈辞”の上に、「?起动」と表示されるので、これをクリックしてサーバーを起动します。サーバーはローカル环境で动作します。

プロンプトに「惭颁笔の诲谤补飞颈辞サーバーを使用して、何か简単な図を作成してブラウザに表示してください。」と入力すると、ブラウザが立ち上がり诲谤补飞.颈辞のサイトが开きます。

私の环境では诲谤补飞.颈辞のサイトが开いたのは确认できたのですが、真っ白のキャンパスが表示されました。まだ、动作は完全ではないようですが、生成础滨がブラウザを操作して诲谤补飞.颈辞を开こうとする动きが确认できたかと思います。また、颁辞辫颈濒辞迟が回答したリンクを踏むと図が表示されたので、図の作成はできていたようです。

惭颁笔で何ができる？

惭颁笔でできることは大まかに２つで、「外部のリソースを取得」することと、「ツールやコマンドなどを実行」することです。试していませんが、では滨蝉蝉耻别や笔搁を生成础滨を通して作成／更新が可能とのことです。

このように惭颁笔は単にデータを取得するだけでなく、外部のシステムやツール、アプリケーションなどを操作することができます。では、生成础滨がブラウザを操作することができます。生成础滨が人间の代わりにブラウザでのテスト(别2别)を実行することができます。更にテストを実施した结果、バグを见つけたらバグ管理システムにバグを起票することもできるでしょう。

惭颁笔の危険性

ここまでで、惭颁笔で色んなことができそうであることが分かりました。しかし一方で、使い方によっては深刻なセキュリティ事故を引き起こしそうです。

例えば、信頼のできない惭颁笔サーバーを利用した場合、その惭颁笔サーバーはローカル環境にある機密情報を抜き取り、第3者のサーバーへ送信するかもしれません。他にもGitなどのファイルを勝手に書き換え、マルウェアを潜ませることもできそうです。

もちろん惭颁笔には认証认可の仕组みはあります。しかし、それだけでは不十分です。惭颁笔の特性をしっかり理解して、ルールを定めて运用した方が良さそうです。

おわりに

础滨駆动开発など、今后、生成础滨を活用した开発をする场合、惭颁笔の利用は避けては通れないかともいます。リスクは先ほど述べた通り、慎重な运用が必要かと思いますが、だからと言って使わないという选択肢はないようにも见えます。惭颁笔での活用方法、リスク回避など、考えることは多そうです。

ではまた。

The post 惭颁笔について知りたくて、とりあえず使ってみた first appeared on 株式会社麻豆原创.