[MCP Prompt] Implement support for MCP prompts

[liliankasem]

Implement support for MCP prompts in the Java worker. This feature allows functions to expose prompt templates that MCP clients can discover, list, and invoke with arguments — enabling structured interactions with language models.

Background

The MCP specification supports prompts as a way for servers to expose reusable prompt templates. Clients can discover available prompts via prompts/list and invoke them via prompts/get, optionally providing arguments. Prompts return a list of messages that can include text, images, audio, or embedded resources.

MCP Specification: https://modelcontextprotocol.io/specification/2025-06-18/server/prompts

Reference Implementation:

• Host-side: Implements the host-side components for MCP prompt support azure-functions-mcp-extension#210
• Worker-side (.NET): Implements the worker-side components for MCP prompt support azure-functions-mcp-extension#211

Host Extension Contract

1. Function Metadata (Binding JSON)

The worker must report prompt functions with the following trigger binding metadata:

{
  "type": "mcpPromptTrigger",
  "direction": "in",
  "name": "<paramName>",
  "promptName": "<unique-prompt-name>",
  "title": "<optional-human-readable-title>",
  "description": "<optional-description>",
  "promptArguments": "<optional-JSON-string-of-argument-definitions>",
  "metadata": "<optional-JSON-string-object>",
  "icons": "<optional-JSON-string-array-of-icons>"
}

The promptArguments field is a JSON-serialized array of argument definitions:

[
  {
    "name": "code",
    "description": "The code to review",
    "required": true
  },
  {
    "name": "language",
    "description": "The programming language",
    "required": false
  }
]

2. Invocation Context

When a prompt is invoked (prompts/get), the host sends the trigger binding data as a JSON-serialized PromptInvocationContext:

{
  "name": "code_review",
  "arguments": {
    "code": "def hello(): ...",
    "language": "python"
  },
  "sessionid": "<session-id-or-null>",
  "transport": {
    "sessionId": "<transport-session-id>",
    "baseUrl": "<base-url>"
  }
}

• name: The prompt name being invoked
• arguments: A flat Dictionary<string, string> — all argument values are strings
• sessionid: May be null
• transport: May be null

3. Return Value Contract

The host extension expects the worker to return a string value. Two formats are accepted:

Option A: Plain string — the host automatically wraps it in a single PromptMessage:

{
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "<the-returned-string>"
      }
    }
  ]
}

Option B: JSON-serialized GetPromptResult — the host deserializes and uses it directly. This is detected by checking if the deserialized object has messages with count > 0 OR description is not null.

{
  "description": "Optional prompt description",
  "messages": [
    {
      "role": "user",
      "content": {
        "type": "text",
        "text": "Please review this Python code:\n\ndef hello():\n    print('world')"
      }
    }
  ]
}

Supported message content types per MCP spec:

• TextContentBlock (type: "text", text: string)
• ImageContentBlock (type: "image", data: base64-string, mimeType: string)
• AudioContentBlock (type: "audio", data: base64-string, mimeType: string)
• EmbeddedResource (type: "resource", resource: { uri, mimeType, text|blob })

Key Considerations

1. Prompt arguments are always strings — unlike tool properties which can have typed JSON schemas, prompt arguments are flat string key-value pairs.

2. Simplest path: Return a plain string from the function. The host handles wrapping it in a PromptMessage with role: "user".

3. Rich responses: For multi-message prompts, mixed roles (user/assistant), or non-text content (images, audio, embedded resources), return a JSON-serialized GetPromptResult.

4. Follow existing tool patterns — The prompt implementation should follow the same worker patterns established for MCP tools (trigger binding, invocation context, return value handling).

5. Metadata support — The metadata and icons fields are optional JSON strings that the host passes through to MCP clients. The worker should support declaring these in the function definition.