MCP: Add check_prerequisites tool for environment validation

[sneharathod7]

Summary

The current MCP healthcheck tool only verifies that the func binary is available and executable. While this is useful for basic validation, it does not cover the broader environment readiness required for an end-to-end serverless workflow.

As part of the agentic workflow initiative discussed in #3646, the agent should be able to proactively validate a developer's local environment before attempting operations such as build, deploy, or invoke.

Right now, failures such as:

• Docker daemon not running
• Invalid or disconnected Kubernetes context
• Missing Knative Serving installation
• Unreachable or misconfigured container registry

are only surfaced indirectly during deployment commands through raw CLI errors. These errors are often difficult for an agent to interpret and difficult for users to act upon.

---

Proposed Solution

Add a new MCP tool:

check_prerequisites

implemented in:

pkg/mcp/tools_prerequisites.go

This tool would perform a structured multi-component environment validation and return actionable diagnostics that an agent can use to guide the user.

---

Proposed Tool Definition

Input

type PrerequisiteRequest struct {
    Verbose bool `json:"verbose"`
}

Output

type PrerequisiteResult struct {
    Ready  bool          `json:"ready"`
    Checks []CheckDetail `json:"checks"`
}

type CheckDetail struct {
    Component string `json:"component"` // docker, cluster, knative, registry
    Status    string `json:"status"`    // ok, warning, error
    Message   string `json:"message"`
    Guidance  string `json:"guidance,omitempty"`
}

---

Validation Scope

The tool could perform the following checks:

1. Container Runtime Availability

Validate that a supported container runtime is available and responsive.

Possible checks:

docker info

or:

podman info

Example failures:

• daemon not running
• permission denied
• binary missing

---

2. Kubernetes Cluster Connectivity

Validate that the current kubeconfig context is usable.

Possible check:

kubectl cluster-info

Example failures:

• invalid kubeconfig
• cluster unreachable
• expired credentials

---

3. Knative Serving Availability

Verify that Knative Serving CRDs are installed and accessible.

Possible check:

kubectl get crd services.serving.knative.dev

This helps detect cases where the cluster exists but the serverless platform is not installed.

---

4. Registry Configuration / Reachability

Validate that a default registry is configured and appears reachable.

Potential checks:

• inspect func.yaml
• inspect global func config
• optional lightweight registry ping

Example failures:

• missing registry configuration
• unreachable registry
• authentication issues

---

Why This Matters

This tool would significantly improve the MCP agent experience by allowing proactive validation instead of reactive failure handling.

Example interaction:

"Docker appears to be installed, but the daemon is not running. Please start Docker Desktop before proceeding."

instead of surfacing a low-level deployment failure later in the workflow.

This aligns directly with the "Prerequisite checks with guidance" deliverable described in #3646 and would improve both:

• agent reliability
• developer onboarding experience

---

Additional Notes

A structured readiness API would also make it easier to:

• surface environment diagnostics in IDE integrations
• support automated setup assistants
• provide richer agent reasoning during deployment workflows

[sneharathod7]

/assign

[sneharathod7]

/assign

[lkingland]

Sounds good to me. Moving this to "active" since it has a related PR.

[lkingland]

The current MCP healthcheck tool only verifies that the func binary is available and executable.

I see where you're going with this, and at first it seems completely reasonable, however the system is actually quite resilient to missing dependencies.

I added some notes on the PR, but the general idea is that the real solution here is to lean heavily into direct usage of the Functions core API in pkg/functions, where the MCP server uses it to expose the core functionality to agents, whereas the cli package exposes it to a terminal.

[sneharathod7]

Hi @lkingland,

Thanks for the detailed feedback and architectural clarification — the reasoning makes a lot of sense.

I was approaching this from a stricter prerequisite-validation perspective, but your comments helped clarify that func is intentionally designed to remain flexible even when components like Docker, kubectl, or Knative are unavailable.

The point about leaning more heavily into structured runtime failures (#3770) instead of upfront validation especially clicked for me.

I also explored the direct pkg/functions integration direction discussed in #3771 and opened a follow-up PR here:
#3780

In that PR, I started migrating MCP operations away from CLI subprocess execution by refactoring the create and delete flows to use pkg/functions directly, along with integration test coverage for the new paths.

Really appreciate the guidance and review comments!

[lkingland]

Closing again — this was deliberately closed on 05-16; the architectural decision is that the broader fix in #3771 (MCP → pkg/functions directly) replaces the need for a check_prerequisites tool as designed. The reopen earlier today was a spurious push from a tooling bug (now fixed in our triage tooling).