Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

support effectful, request-aware annotations for MCP

オープン
  • 何か問題がありますか？
#9,610 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
32/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend-api-design

調査の方向性

Start by reading McpSchema.EnabledWhen, the tool annotation APIs, and the HTTP request scoped server setup mentioned in the issue. Work out how effectful annotations should run with authenticated request services and how their dependencies interact with shared server services, including subscriptions and legacy reverse requests. Done means a design and implementation that supports request-aware annotations with clear execution rules and tests for per-caller visibility and metadata.

索引モデルが issue の本文から書いたものです。

説明

enhancement
What is the problem this feature would solve?

Is there any way to have the EnabledWhen from McpSchema be based on an Effect? Or another approach to achieve that behavior?

The tools we expose are based on user permissions and customer settings
~ David (Discord)

Currently its quite difficult to expose tools based on the authenticated user's permissions and customer settings. These checks can require database or service calls and if we want one shared MCP server to filter tools for each caller and check access is needed again before execution.

McpSchema.EnabledWhen currently accepts a sync predicate over protocol version, client capabilities, and client information, but it cannot run an Effect or receive authenticated request services. Checking permissions inside a handler protects execution, but the tool still appears in tools/list.

The same need can apply to other annotations. For example, a tool's title or metadata could depend on customer settings or the user's locale. Could we support effectful annotations generally, with clear rules about when they run?

What is the feature you are proposing to solve the problem?

One option is to keep .annotate for static values and add .annotateEffect for values computed when handling a request:

const JokeTool = Tool.make("DadJoke", {
	parameters: Tool.EmptyParams,
	success: Schema.String
})
	.annotateEffect(
		McpSchema.EnabledWhen,
		Effect.gen(function*() {
			const user = yield* CurrentUser
			const permissions = yield* Permissions
			const allowed = yield* permissions.hasSenseOfHumor(user)
			return () => allowed
		})
	)
	.annotateEffect(
		Tool.Title,
		Effect.gen(function*() {
			const user = yield* CurrentUser
			const settings = yield* UserSettings
			return yield* settings.notSafeForWorkTitle(user.id)
		})
	)

The example returns a predicate because that is EnabledWhen's current value type. Allowing an effectful predicate directly could be another option, but would only address visibility.

CurrentUser, Permissions, and UserSettings are application services. Authentication provides the principal for the current request. Client-supplied MCP metadata is not proof of identity. The API would need to track these dependencies and distinguish request services from shared application services.

What alternatives have you considered?

We can load permissions with an Effect, then capture the result in EnabledWhen. For different callers, our example builds a fresh registry inside each HTTP request using Layer.fresh and McpServer.layerHttpRequestScoped.

This works, but rebuilds the registry for each request and requires sessionless clients. It does not support subscriptions or legacy reverse requests. We would like request-aware annotations without requiring this server setup.

主要言語
TypeScript
スター
16.7k
フォーク
808
平均マージ
10時間 7分
マージ済み PR（30日）
808

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Effect-TS/effect のほかの issue

Effect-TS/effect の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。