Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

support effectful, request-aware annotations for MCP

Aperta
  • Qualcosa non va?
#9,610 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend-api-design

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
TypeScript
Stelle
16.7k
Fork
808
Merge medio
12h 7m
PR unite (30g)
844

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Effect-TS/effect

Tutte le issue di Effect-TS/effect

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.