You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once func supports a --json flag (#3769), the MCP server should invoke func with --json everywhere and forward the structured payload to MCP clients via CallToolResult.StructuredContent — replacing all output parsing / error scraping currently done (or attempted) on the MCP side.
The MCP server currently treats func as a text-emitting black box: it captures stdout/stderr and either presents the blob to the agent verbatim or tries to classify it heuristically. Both shapes are dead ends:
Verbatim text gives agents no machine-readable handle to dispatch on.
Once func --json exists, the right MCP wrapper is roughly:
result, err := executor.Run("func", "build", "--json", ...)
// parse result.Stdout as the envelope from #3769
// on success: stick payload in StructuredContent
// on error: stick error object in StructuredContent, set IsError=true
Required changes
Invoke func with --json in every MCP tool handler (build, deploy, delete, create, list, describe, invoke, all config_*, healthcheck, etc.). Currently inconsistent — only some handlers attempt any structure at all.
Populate CallToolResult.StructuredContent with the parsed JSON, not TextContent. MCP already has a machine-readable channel; use it.
Surface the full error taxonomy to agents: READONLY_ERROR, TIMEOUT_ERROR, and any other categories func emits — don't drop them on the floor.
Forward the retryable / transient boolean from the structured error. This is the actual dispatch signal agents need ("try again" vs "give up").
Keep TextContent populated with a short human-readable summary for fallback / log display, but the canonical channel is StructuredContent.
Remove the in-MCP categorization heuristics entirely — func is the source of truth.
Summary
Once
funcsupports a--jsonflag (#3769), the MCP server should invokefuncwith--jsoneverywhere and forward the structured payload to MCP clients viaCallToolResult.StructuredContent— replacing all output parsing / error scraping currently done (or attempted) on the MCP side.Depends on
--jsonoutput mode to everyfuncsubcommand, including errors #3769 —--jsonoutput mode on everyfuncsubcommand (prerequisite). This issue is implementable only after that lands.Motivation
The MCP server currently treats
funcas a text-emitting black box: it captures stdout/stderr and either presents the blob to the agent verbatim or tries to classify it heuristically. Both shapes are dead ends:Once
func --jsonexists, the right MCP wrapper is roughly:Required changes
funcwith--jsonin every MCP tool handler (build,deploy,delete,create,list,describe,invoke, allconfig_*,healthcheck, etc.). Currently inconsistent — only some handlers attempt any structure at all.CallToolResult.StructuredContentwith the parsed JSON, notTextContent. MCP already has a machine-readable channel; use it.READONLY_ERROR,TIMEOUT_ERROR, and any other categoriesfuncemits — don't drop them on the floor.retryable/transientboolean from the structured error. This is the actual dispatch signal agents need ("try again" vs "give up").TextContentpopulated with a short human-readable summary for fallback / log display, but the canonical channel isStructuredContent.funcis the source of truth.Related
--jsonoutput mode to everyfuncsubcommand, including errors #3769 are scoped.funcrather than MCP.Non-goals
--jsonoutput mode to everyfuncsubcommand, including errors #3769's job.