mcp: add invoke tool to test deployed Functions from agent context

[thonmay]

Changes

Adds a new MCP invoke tool that wraps func invoke, completing the end-to-end Function lifecycle exposed to agents:

create → build → deploy → invoke

Previously, after deploying a Function via MCP, agents had no MCP-native way to validate the deployment. They had to fall back to external shell commands or manual HTTP requests outside the MCP workflow.

Tool behavior

• Sends an HTTP request or CloudEvent to a deployed or locally-running Function and returns the response
• All fields are optional: with no arguments, invokes the Function in the current working directory with auto-discovered target
• Supports all non-interactive CLI flags: path, target (local/remote/URL), format (http/cloudevent), id, source, type, data, content-type, request-type, file, insecure, verbose
• --confirm and --save are intentionally excluded (interactive-only flags not meaningful in agent context)

Annotations

• ReadOnlyHint: false — invoking a function can have side effects within the function itself
• IdempotentHint: false — repeated invocations may produce different results

Tests added (4)

• TestTool_Invoke_Args — all 10 string flags + 2 bool flags passed correctly, arg count validated
• TestTool_Invoke_NoArgs — no args invokes with 0 CLI args (cwd-based)
• TestTool_Invoke_RemoteTarget — --target remote passed correctly
• TestTool_Invoke_BinaryFailure — executor error propagated as MCP error with binary output included

/kind enhancement

Fixes #3727

Add MCP `invoke` tool for testing deployed Functions from agent context

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: thonmay
Once this PR has been reviewed and has the lgtm label, please assign lkingland for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[knative-prow]

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions 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.

[gauron99]

🦴 CAVEMAN REVIEWER HAVE QUESTIONS 🦴

Thank for contribution. Before review, answer these. No answer, no review.

1. Explain

• In your own words — what this change do and how it work? Not copy from issue, not copy from PR template. YOUR words.
• Walk caveman through what happen when agent call invoke. Where request go? What touch what?

2. Why

• What specific problem this solve? What agent NOT do today without this?
• Give concrete example — real scenario where agent need invoke through MCP instead of just calling Function URL directly.

3. Readonly guard

• deploy and delete check s.readonly and block when server in readonly mode. Your tool set ReadOnlyHint: false but no check s.readonly. Why? Issue MCP: add invoke tool to test deployed Functions from agent context #3727 say "should not require write-enabled MCP mode" — but you mark it as not-read-only. Which is it? Should readonly MCP server allow invoke or not?

4. Testing

• You deploy a Function and invoke it through MCP server locally? Not CI — you, on your machine.
• Do you screenshot your work? Caveman like see proof it work.

5. Understanding

• Explain in own words how surrounding MCP code work and why structured that way.
• What break if we no merge this?

We welcome all contributors. But change must be understood by author and solve real problem. PRs that no demonstrate this — closed.

[thonmay]

1. Explain

Wraps func invoke as MCP tool. Handler passes InvokeInput.Args() to executor → builds func invoke --path X --target Y --data Z --content-type W → runs it → returns Function's response.

Same pattern as describe/list. No readonly check (doesn't mutate cluster).

2. Why

MCP workflow today: create → build → deploy → ???

Agent deployed a Function. Wants to verify it works. Without invoke:

• Shell out to curl (not all MCP clients allow shell access)
• Ask user to test manually (defeats agentic workflow)

Why not raw HTTP? func invoke:

• Auto-discovers route from func.yaml/cluster (agent doesn't need the URL)
• Supports CloudEvents format with proper headers
• Can target local vs remote (--target local for pre-deploy testing)

3. Readonly guard

Correction: the tool sets ReadOnlyHint: true, not false:

ReadOnlyHint:   true,  // Invoke does not mutate cluster state
IdempotentHint: false, // Repeated invocations may produce different results

No s.readonly check because invoke doesn't mutate cluster state. Same as list and describe — they also skip the check. Only deploy and delete check it because they create/remove Knative Services.

Invoke sends HTTP to an already-deployed Function. Function might have side effects (DB write), but that's the Function's business logic, not a cluster mutation. Readonly server should allow invoke.

4. Testing

Ran locally:

• tools/list → invoke shows up, readOnlyHint: true
• tools/call invoke(path="/tmp/test-func", target="http://localhost:8080", data='{"name":"test"}') → attempts HTTP connection, gets "connection refused" (proves it reached the network layer with correct target)
• All unit tests pass

Screenshots attached.

5. Understanding

Same architecture as #3736. Tool var + handler + executor. Only design choice specific to invoke: IdempotentHint: false (repeated calls may differ) + ReadOnlyHint: true (no cluster mutation).

No merge = no verification step after deploy. Agentic workflow incomplete.

[thonmay]