RFC-0060: Starlark Session Initialization for vMCP#60
Open
RFC-0060: Starlark Session Initialization for vMCP#60
Conversation
jerm-dro
force-pushed
the
jerm/2026-03-24-starlark-programmable-middleware
branch
from
b57f13b to
1fde39a
Compare
jerm-dro
commented
Mar 25, 2026
jerm-dro
commented
Mar 25, 2026
jerm-dro
changed the title
yrobla
requested changes
Mar 30, 2026
Contributor
yrobla
left a comment
yrobla
left a comment
There was a problem hiding this comment.
Strong RFC overall — the problem framing, prior art, and alternatives section are all excellent. The backends() + publish() model is clean, and the default preset sketch makes backward compatibility concrete rather than aspirational.
Filing 3 blockers, 3 should-address items, 2 questions, and 2 nits.
JAORMX
reviewed
Mar 31, 2026
Contributor
There was a problem hiding this comment.
I like the proposal and think that overall this is a good step to provide more customizability and programmability to vMCP. I'd be wary of fully relying on this mechanism for vMCP's programmability, API Gateways tend to offer programming languages as pluggability options (as you mentioned, Envoy's usage of Lua) but they often don't recommend them for critical paths and instead opt for other type of programmability or extensions. e.g. ext_proc via a sidecar which is quite standard to see in the wild or even c++ extensions since they support that too. For us it's a little tricky to know without previous data. So I'd say let's start getting it by adding this addition, but still opt for built-in middleware for extensibility since that's the paved path we have today. e.g. rate limiting should still be implemented via dedicated middleware IMO.
yrobla
reviewed
Mar 31, 2026
Contributor
yrobla
left a comment
yrobla
left a comment
There was a problem hiding this comment.
Good RFC overall — the core argument (config knob interactions grow quadratically, Starlark + built-ins inverts this) is solid and the prior art section grounds it well. Comments below on a few specific areas.
Proposes extending vMCP's Starlark engine from composite-tool-only scripting into a unified programmable middleware surface, replacing the growing set of independent config knobs (optimizer, filter, rate limiting, PII scrubbing) with a single script per session. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: Jeremy Drouillard <jeremy@stacklok.com>
- Rename "middleware script" → "session initialization script" throughout - backends() returns dict[string, Backend] instead of flat tools() list - Handler functions take single dict arg instead of **kwargs - metadata() requires all fields (name, description, parameters, annotations) - Rewrite presets section: no config nesting, auto-generation from existing config - Update sequence diagram: remove Starlark Engine, use MultiSession - Restructure implementation phases: feature parity first, then new capabilities - Simplify Cedar interaction section - Remove THV-0058 reference - Update open questions (remove resolved, add error handling) - Rename CRD to VirtualMCPSessionInitScript - Rename config struct to SessionInitConfig Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Rewrite authz model: scripts see all backends, authz filters at runtime - Add Background section explaining how authorization works today - Replace call_tool() with saved handler dict pattern in all examples - Collapse three presets into single `default` preset with ~80-line sketch - Add handler timeout support (optional kwarg) - Move current_user() to future built-ins (user known at init, deferred) - Fix scrub_pii() as future built-in example, not v0 deliverable - Add config() built-in for preset access to persona config - Expand Alternatives Considered: configuration approaches + language considerations (Starlark, Risor, Wasm, Lua, OPA/Rego) - Add 4-phase implementation plan (POC → production → deprecate → ship) - Update Why Now with cost equation argument - Clarify scope: enabling new capabilities, not shipping them Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reference stacklok/toolhive#4373 as a concrete example of feature interaction pain in the Problem Statement. Add open question about whether authz decisions should move into Starlark to unify the "who sees what?" model. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The optimizer/Cedar issues (#4373, #4374) are about the authz boundary, not config knob combinations. Move them to Open Question 2 where they motivate pulling authz into Starlark. Use #4287 as the Problem Statement example instead. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add "Prior Art: Gateway Configurability Patterns" covering Envoy, Kong, and the Configuration Complexity Clock. Add vMCP feature dependency diagram to the Problem Statement. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
…tion Split monolithic "Config knob combinations" into two focused sections: "The configurability problem" (user-facing interaction examples) and "The maintainability problem" (developer-facing quadratic cost). Move Background (prior art + authz) under Proposed Solution where it provides context for the design. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Reframe problem as configurability vs maintainability tension. Move bug evidence and dependency diagram to maintainability section. Remove feature table (duplicative with diagram). Update summary to mirror problem framing. Add links to Envoy, Kong, and Configuration Complexity Clock resources. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Elaborate rate limiting interaction questions (composite tools, groups). Add optimizer × authz bugs (#4373, #4374) to maintainability section. Replace PII hypothetical with concrete framing. Add Envoy and Kong source code snippets with GitHub links to prior art section. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Replace hand-written code snippets with examples from official documentation. Link to doc pages instead of source files. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Move Motivating Use Cases to Appendix A - Update Last Updated date to 2026-03-27 - Replace scrub_pii decorator example with v0 logging decorator - Restore missing filter decorator in architecture diagram - Remove duplicate composite tools mentions from presets/config sections - Note composite tools support is optional in compatibility section - Fix Open Question 3 bold formatting Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The CI validator checks all new files under rfcs/ for the THV-#### naming convention. Move the image to images/ at the repo root. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Add Alternative 2 covering Go code refactoring as a competing approach. Acknowledge its value while noting it doesn't address configurability or cross-cutting concerns. Include AI-driven development observation. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix priority_order.index() crash for unranked backends in default preset - Inline FIND_TOOL_SCHEMA and CALL_TOOL_SCHEMA in default preset sketch - Add when_unavailable parameter to elicit() for non-elicitation clients - Make preset/script/scriptFile mutual exclusion a hard validation error - Resolve error handling open question: MCP-standard isError response dicts - Keep existing decorators in Phase 1 POC, delete in later phases - Clarify session scope: runs once per session creation or Redis restore - Restructure rollout: safe capabilities first, optimizer + authz together - Add warning about handler dispatch bypassing Cedar authz (#4374) - Reference PR #4385 as interim fix for optimizer + authz bypass - Resolve authz open question: ship with optimizer, defer exact design - Add thv vmcp list-presets command Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Restructure implementation plan into 3 phases: POC (with rate limiting benchmark), backwards compatibility, new functionality - Update rate limiting interaction section: THV-0057 ships as standalone middleware first, Starlark built-in benchmarked later - Clarify current_user() returns same value for session lifetime - Add security section note on identity-based filtering being intentional and complementary to Cedar - Rewrite Open Question 1: note two-hook model as future direction for sessionless MCP, remove ordering heuristic Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jerm-dro
force-pushed
the
jerm/2026-03-24-starlark-programmable-middleware
branch
from
4df7d2f to
a4dcada
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Introduce a Starlark-based session initialization script for vMCP. A single script runs once per session, receives discovered backends and their capabilities, and calls
publish()to declare what the agent sees — optionally wrapping handlers with additional logic. Existing config knobs remain fully supported, but customization of vMCP behavior can now be exactly tailored to the use case without adding more knobs. Increasing configurability no longer means decreasing maintainability.