Repository navigation
Conversation
knative-prow
Bot
added
the
kind/enhancement
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: thonmay The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
knative-prow
Bot
added
size/L
|
Hi @thonmay. Thanks for your PR. I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with Regular contributors should join the org to skip this step. Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
🦴 CAVEMAN REVIEWER HAVE QUESTIONS 🦴 Thank for contribution. Before review, answer these. No answer, no review. 1. Explain
2. Why
3. Testing
4. Understanding
We welcome all contributors. But change must be understood by author and solve real problem. PRs that no demonstrate this — closed. |
|
1. Explain Adds Also includes describe tool from #3736. You're right, separate changes. I'll rebase this to prompt-only, keep describe in #3736. 2. Why Option 1 (set flag false) = fix the lie, add no value. Agent sees 17 tools and several resources. Doesn't know the order, doesn't know MCP clients (Claude Desktop, Cursor) expose prompts to users. User picks "func-workflow" → agent gets a structured plan. Tools are individual actions; prompt is the recipe. Without it, agent relies on instructions.md (long, may get truncated in some clients). 3. Testing Ran locally:
Screenshots attached. 4. Understanding Tools = model-controlled, agent calls them to DO things. Agent uses tool when it knows what to do. User invokes prompt when they want guided help. No merge = |
|
Adds a 'func-workflow' MCP prompt that guides agents through the full Function lifecycle: create, build, and deploy. Accepts an optional 'language' argument to tailor the guidance. This resolves the HasPrompts: true capability flag being advertised without any prompts registered, which could mislead MCP clients. Fixes knative#3734 Signed-off-by: Thonmay <mdthoriqulislam384@gmail.com>
e68747d to
f6c8a57
Compare
|
/ok-to-test |
knative-prow
Bot
added
ok-to-test
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #3737 +/- ##
==========================================
+ Coverage 57.03% 57.10% +0.07%
==========================================
Files 182 183 +1
Lines 21376 21409 +33
==========================================
+ Hits 12191 12225 +34
Misses 7953 7953
+ Partials 1232 1231 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
knative-prow-robot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
The onboard prompt ran its local run and invoke before asking for a registry, on the theory that proving the Function works should not require one. It does: the default builder is pack, so a local run builds a container image, and naming that image needs a registry. Without one the build fails with "registry required" — for exactly the first-time user the prompt exists to serve, at a step the prompt forbids skipping past. Registry configuration is now step 4 and the local run step 5, which passes the gathered registry to run. Read-only mode omitted the registry step along with deploy and the remote invoke, yet still rendered "ask the user in step 5" in the parameters table, asked for a registry in the summary, and closed by telling the user to re-run deploy, which read-only refuses. The registry step is no longer omitted — a local build has to name an image whether or not it is ever pushed — and the remaining deploy-dependent text is now conditional. Language and template were validated against hardcoded lists. Which runtimes and templates exist depends on the installed binary and on any repositories added with the repository_add tool this same server exposes, so those lists rejected legitimate values outright. Only cluster is validated now, being prompt-internal and never passed to func; the rest are trimmed and passed through with their case intact, since a fold would corrupt the very repository-supplied names the lists used to reject. The agent is still told to check them against func://languages and func://templates. The deploy step named go and python as the host builder's runtimes. It now branches on oci.IsSupported, leaving pkg/oci the only place that list lives. Also: drop step 3's question about a Function name, there being no name argument to carry it (the name is the directory basename); drop the instruction to cd, which nothing depends on now that every tool call takes an absolute path; and assert table values in tests through a padding-insensitive match, so realigning the markdown cannot fail the build. Relates to knative#3737
* feat(mcp): add parameterized 'onboard' prompt The server advertised prompts capability but registered none. Add the first: 'onboard', a multi-step workflow driving an agent end-to-end from an empty directory to a deployed, invocable Function. The eight steps map onto existing tools and resources: version (with a kubectl-context check), func://languages, create, run + invoke --target local + run_stop, registry elicitation, deploy + describe, invoke --target remote, and a summary read back out of tool output rather than out of what was requested. All four arguments (language, template, registry, cluster) are optional. Supplied values are rendered into the prompt and marked as decided; omitted ones render as an explicit instruction to ask the user at the relevant step, since neither a language nor a registry has a sane default. template defaults to http and cluster to local. Values are normalized (case, whitespace) and validated, with "cloudevent" resolving to the "cloudevents" template that actually exists on disk; the registry keeps its case, being an image reference prefix. Unrecognized values are rejected rather than rendered, so the agent is never sent off to run a command that cannot succeed. The prompt body is an embedded text/template, mirroring how the server's instructions are embedded. In read-only mode the registry, deploy and remote-invoke steps are omitted rather than handed to an agent that would be refused, and the user is told to restart with FUNC_ENABLE_MCP_WRITE=true. * chore: re-trigger CI The lint job failed fetching the golangci-lint JSON schema from golangci-lint.run (network timeout), not on anything in this change. * fix(mcp): gather registry before the local run The onboard prompt ran its local run and invoke before asking for a registry, on the theory that proving the Function works should not require one. It does: the default builder is pack, so a local run builds a container image, and naming that image needs a registry. Without one the build fails with "registry required" — for exactly the first-time user the prompt exists to serve, at a step the prompt forbids skipping past. Registry configuration is now step 4 and the local run step 5, which passes the gathered registry to run. Read-only mode omitted the registry step along with deploy and the remote invoke, yet still rendered "ask the user in step 5" in the parameters table, asked for a registry in the summary, and closed by telling the user to re-run deploy, which read-only refuses. The registry step is no longer omitted — a local build has to name an image whether or not it is ever pushed — and the remaining deploy-dependent text is now conditional. Language and template were validated against hardcoded lists. Which runtimes and templates exist depends on the installed binary and on any repositories added with the repository_add tool this same server exposes, so those lists rejected legitimate values outright. Only cluster is validated now, being prompt-internal and never passed to func; the rest are trimmed and passed through with their case intact, since a fold would corrupt the very repository-supplied names the lists used to reject. The agent is still told to check them against func://languages and func://templates. The deploy step named go and python as the host builder's runtimes. It now branches on oci.IsSupported, leaving pkg/oci the only place that list lives. Also: drop step 3's question about a Function name, there being no name argument to carry it (the name is the directory basename); drop the instruction to cd, which nothing depends on now that every tool call takes an absolute path; and assert table values in tests through a padding-insensitive match, so realigning the markdown cannot fail the build. Relates to #3737 * chore: re-trigger CI
Changes
Adds a
func-workflowMCP prompt that guides agents through the full Function lifecycle: create, build, and deploy.Why Option 2 (add a real prompt) over Option 1 (set HasPrompts: false):
Setting the flag to false would be a minimal fix but leaves the capability unused. A guided workflow prompt is directly useful to agents and aligns with the MCP server's purpose of enabling end-to-end agentic usage of Functions.
Prompt behavior:
func-workflowlanguageargument to tailor guidance (e.g. go, python, node)HasPrompts: trueremains correct now that a prompt is registeredTests added (3):
TestPrompt_Listed— prompt appears in ListPrompts responseTestPrompt_Get— prompt returns valid message with create/deploy contentTestPrompt_GetWithLanguage— language argument is reflected in output/kind enhancement
Fixes #3734