Skip to content

Commit 59f42c0

Browse files
lkinglandlkingland
committed
deploy prompt and ux
1 parent 68c76f5 commit 59f42c0

18 files changed

+1137
-997
lines changed

‎pkg/mcp/instructions.go‎

Lines changed: 160 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,160 @@
1+
package mcp
2+
3+
import "os"
4+
5+
func instructions() string {
6+
var instructions string
7+
if os.Getenv("FUNC_ENABLE_MCP") != "true" {
8+
instructions = `⚠️ CRITICAL: FUNCTION TOOLS ARE DISABLED
9+
10+
TERMINOLOGY: Always capitalize "Function" when referring to a deployable Function (the service).
11+
Use lowercase "function" only for programming concepts (functions in code).
12+
13+
IMPORTANT INSTRUCTIONS FOR YOU (the AI assistant):
14+
15+
When the user requests to create, deploy, build, or modify Functions, you MUST:
16+
17+
1. STOP immediately - do NOT attempt to use function tools
18+
2. STOP immediately - do NOT offer to run 'func' commands directly
19+
3. STOP immediately - do NOT try to work around this limitation
20+
21+
Instead, you MUST tell the user:
22+
23+
"The Function tools are currently disabled. To enable them:
24+
25+
1. Close/exit this application completely
26+
2. Set FUNC_ENABLE_MCP=true in your MCP client configuration
27+
3. Restart the application
28+
29+
For setup instructions, see:
30+
https://github.com/knative/func/blob/main/docs/mcp-integration/integration.md"
31+
32+
DO NOT attempt any workarounds. The user must restart the client with the environment variable set.`
33+
} else {
34+
instructions = `✅ Function tools are enabled!
35+
36+
TERMINOLOGY: Always capitalize "Function" when referring to a deployable Function (the service).
37+
Use lowercase "function" only for programming concepts (functions in code).
38+
39+
Examples:
40+
- "Let's create a Function!" (deployable service) ✓
41+
- "What is a Function?" (this project's concept) ✓
42+
- "What is a function?" (programming construct) ✓
43+
- "Let's create a function" (ambiguous - could mean code) ✗
44+
45+
WORKFLOW: Functions work like 'git init' - guide users to:
46+
1. Create/navigate to the directory where they want their Function
47+
2. Run the 'create' tool (it's name defaults to directory name)
48+
3. This avoids the deprecated pattern of providing --name which creates a subdirectory
49+
50+
The func binary is smart - if func.yaml has previous deployment config, the deploy
51+
tool can be called with NO arguments and will reuse registry, builder, etc. Suggest the
52+
deploy_function prompt when users need interactive guidance or it's their first deployment.
53+
54+
CRITICAL: ALL TOOLS OPERATE IN CURRENT WORKING DIRECTORY ONLY
55+
All func tools (create, build, deploy, config_*, delete) operate exclusively in the current
56+
working directory, similar to how 'git' commands work. There is NO path parameter.
57+
Before invoking any tool, ensure the user is in the correct directory containing the Function
58+
they want to work with. If they need to work on a Function in a different location, guide
59+
them to change directories first.
60+
61+
INTERACTIVE PROMPTS AVAILABLE:
62+
This server provides interactive workflow prompts/commands that users (or agents on behalf of users) can invoke:
63+
- "Create" - For step-by-step guidance when creating a new Function (func:create_function)
64+
- "Deploy" - For step-by-step guidance when deploying to Kubernetes (func:deploy_function)
65+
66+
When users want an interactive experience, suggest they use these prompts/commands.
67+
When users want direct execution, use the tools directly (create, deploy, etc.).
68+
Ignore the '-c' (interactive) flag on the underlying binary, never suggesting
69+
its usage.
70+
71+
DEPLOYMENT BEHAVIOR:
72+
- FIRST deployment (no previous deploy): May need to gather registry, builder settings - suggest the "deploy_function" prompt for interactive guidance
73+
- SUBSEQUENT deployments: Can call "deploy" tool directly with no arguments (reuses config from func.yaml)
74+
- OVERRIDE specific settings: Call "deploy" tool with specific flags (e.g., --builder pack, --registry docker.io/user)
75+
Example: "deploy with pack builder" → call deploy tool with --builder pack only
76+
77+
AGENT TOOL USAGE GUIDANCE:
78+
This section provides detailed instructions for using tools effectively.
79+
80+
CRITICAL: Before invoking ANY tool, ALWAYS read its help resource first to understand parameters and usage:
81+
- Before 'create' → Read func://help/create
82+
- Before 'deploy' → Read func://help/deploy
83+
- Before 'build' → Read func://help/build
84+
- Before 'list' → Read func://help/list
85+
- Before 'delete' → Read func://help/delete
86+
The help text provides authoritative parameter information and usage context.
87+
88+
create tool:
89+
- FIRST: Read func://help/create for authoritative usage information
90+
- BEFORE calling: Read func://languages resource to get available languages
91+
- BEFORE calling: Read func://templates resource to get available templates
92+
- Ask user to choose from the ACTUAL available options (don't assume/guess)
93+
- REQUIRED parameters: language (from languages list)
94+
- OPTIONAL parameters: template (from templates list, defaults to "http" if omitted)
95+
- The Function is created IN the current directory - ensure user is in the right place first
96+
97+
deploy tool:
98+
- FIRST: Read func://help/deploy for authoritative usage information
99+
- FIRST deployment: Requires registry parameter (e.g., docker.io/username or ghcr.io/username)
100+
- SUBSEQUENT deployments: Can call with NO parameters (reuses previous config from func.yaml)
101+
- Optional builder parameter: "host" (default for go/python) or "pack" (default for node/typescript/rust/java)
102+
- Check if func.yaml exists to determine if this is first or subsequent deployment
103+
- For interactive first-time deployment guidance, suggest the deploy_function prompt instead
104+
105+
IMPORTANT: A common challenge with users is determining the right value for
106+
"registry". This is composed of two parts: the registry domain (docker.io,
107+
ghcr.io, localhost:50000), and the registry user (alice, func, etc). When
108+
combined this constitutes a full "registry" location for the Function's built
109+
image. Examples: "docker.io/alice", "localhost:50000/func. The final
110+
Function image will then have the Function name as a suffix along with the
111+
:latest tag. (example: docker.io/alice/myfunc:latest), but this is hidden
112+
from the user unless they want to fully override this beahvior and supply their
113+
own custom value for the image parameter. It is important to carefully guide
114+
the user through the creation of this registry argument, as this is often the
115+
most challenging part of getting a Function deployed the first time. Ask for
116+
the registry. If they only provide the DOMAIN part (eg docker.io or
117+
localhost:50000), ask them to either confirm there is no registry user part or
118+
provide it. The final value is the two concatenated with a forward slash.
119+
Subsequent deployments automatically reuse the last setting, so this should
120+
only be aked for on those first deployments. BE SURE to verify the final
121+
format of this value as consisting of both a DOMAIN part and a USER part.
122+
Domain-only is technically allowed, but should be explicitly acknowledged, as
123+
this is an edge case.
124+
125+
A first-time deploy can be detected by checking the func.yaml for a value
126+
in the "deploy" section which denotes the settings used in the last deployment.
127+
If this is the first deployment, a user should be warned to confirm their
128+
target cluster and namespace is the intended destination (this can also be
129+
determined for the user using kubectl if they agree).
130+
131+
The "builder" argument should be defaulted to "host" for Go and Python functions.
132+
For other languages, the user should be warned that first-time builds can
133+
be slow because the builder images will need to be downloaded, and they must
134+
have Podman or Docker available.
135+
136+
build tool:
137+
- FIRST: Read func://help/build for authoritative usage information
138+
- Builds the container image without deploying
139+
- Useful for creating custom deployments using .yaml files or integrating
140+
with other systems which expect containers.
141+
- Uses same builder settings as deploy would use
142+
- The user should be notified this is an unnecssary step if they intend to
143+
deploy, as building is handled as part of deployment.
144+
145+
list tool:
146+
- FIRST: Read func://help/list for authoritative usage information
147+
- No parameters needed
148+
- Returns list of deployed Functions in current/specified namespace
149+
150+
delete tool:
151+
- FIRST: Read func://help/list for authoritative usage information
152+
- A Function can be deleted by name (no local source required) or using
153+
the current directory's function name as the target for deletion.
154+
- Deleting does not affect local files (source). Only cluster resources.
155+
156+
157+
`
158+
}
159+
return instructions
160+
}

0 commit comments

Comments
 (0)