feat(templates): support mcp python runtimes - #2155
Conversation
|
Claude Security Review: no high-confidence findings. (run) |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## refactor #2155 +/- ##
============================================
+ Coverage 97.22% 97.25% +0.02%
============================================
Files 507 507
Lines 33809 33881 +72
============================================
+ Hits 32872 32951 +79
+ Misses 937 930 -7 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
AgentCore Harness Review
Verdict: Changes requested
Mostly clean, but there's one inconsistency worth fixing before merging.
protocol isn't treated as a scaffolding flag in add runtime
src/handlers/project/create/index.ts (lines 230–240) correctly adds "protocol" to scaffoldingChoiceFlags, so agentcore create --name x --protocol MCP engages the custom-scaffold path and Zod validates that language/framework are present.
src/handlers/project/add/runtime/index.ts (lines 129–137) does not include "protocol" in scaffoldingFlags. As a result, agentcore add runtime --name my_agent --protocol MCP (no other scaffolding flags) computes isCustom = false, falls through to the resolveRuntimeTemplateShortcut("hello-world-python", { runtimeName }) default, and produces a spec where:
scaffoldRuntimeInput.protocolisundefined→ files scaffolded fromhello-world-python(HTTP-only Python template)runtimeInput.protocol="MCP"(from line 224) →spec.runtimes[0].protocol = "MCP"
The user ends up with an MCP-declared runtime backed by HTTP hello-world code, with no error surfaced. Now that MCP is a first-class scaffolding choice, this silent mismatch is worth fixing.
Fix options (pick one):
- Add
"protocol"to thescaffoldingFlagsarray inadd/runtime/index.tsso--protocolalone drivesisCustom = true; the existingScaffoldRuntimeInputSchema.safeParsewill then reject missinglanguage/frameworkwith a clear error, matchingcreate. - Explicitly reject
--protocolwithout--template/--framework/--languageinadd/runtime/index.tswith anInputValidationErrorthat names the required companion flags.
A regression test in src/handlers/project/add/runtime/index.test.ts covering --protocol MCP alone (in the rejection block) would lock this in.
Nits (non-blocking, no action required)
- The
strands-py-mcpshortcut setsframework: "strands"even thoughpyproject.tomldoesn't pull instrands-agents— the shortcut key drives resolver routing rather than declaring an actual dependency, which is fine, but the naming is a little misleading. Not a blocker. strands-py-mcpstill allows--protocol HTTPas an override, which would route to thestrands-http-pythontemplate but keep themcp_serverruntime name from the shortcut. Consider constraining overrides for template presets where the protocol is intrinsic (again, not a blocker).
|
Claude Security Review: no high-confidence findings. (run) |
|
Claude Security Review: no high-confidence findings. (run) |
|
Addressed the harness reviewer comments by keying the templates by protocol, and renaming to py-mcp. |
Problem
We're missing support for deploying mcp servers onto runtimes.
Solution
--protocolflag to the scaffolding flows in add and create.Verification.
had an agent verify the same flow for container-based.