Workflow:Microsoft Semantic kernel Plugin Integration And Function Calling
| Knowledge Sources | |
|---|---|
| Domains | AI_Orchestration, Function_Calling, Plugins |
| Last Updated | 2026-02-11 18:00 GMT |
Overview
End-to-end process for extending a Semantic Kernel instance with plugins (native C# functions, prompt functions, and OpenAPI specifications) and enabling the AI model to autonomously select and invoke them via function calling.
Description
This workflow demonstrates how to give the AI model access to external capabilities through the Semantic Kernel plugin system. Plugins are collections of kernel functions that the model can discover, reason about, and invoke during a conversation. The workflow covers three plugin types: native C# plugins (annotated classes), prompt-based plugins (YAML or inline templates), and OpenAPI plugins (imported from REST API specifications). It then configures automatic function calling, where the AI model decides which plugins to invoke based on the user's request, and manual function calling, where the application retains control over invocation.
Usage
Execute this workflow when you need the AI model to perform actions beyond text generation, such as retrieving live data (current time, weather, database lookups), calling external APIs, or executing domain-specific business logic. This is required whenever the model must interact with the outside world rather than relying solely on its training data.
Execution Steps
Step 1: Define Native Plugin Classes
Create C# classes with methods annotated using the KernelFunction attribute. Each method becomes a callable function that the AI model can discover and invoke. Add Description attributes to methods and parameters so the model understands when and how to use each function.
Key considerations:
- Methods must be decorated with [KernelFunction] to be discoverable
- [Description] attributes on methods and parameters guide the AI's selection
- Enum parameters require [JsonConverter(typeof(JsonStringEnumConverter))] for serialization
- Return types can be primitives, objects, or Task-wrapped async results
Step 2: Register Plugins on the Kernel
Add plugin classes to the kernel builder's plugin collection. The framework uses reflection to discover all KernelFunction-annotated methods and registers them as available tools.
Pseudocode:
kernelBuilder.Plugins.AddFromType<TimeInformation>() kernelBuilder.Plugins.AddFromType<WidgetFactory>()
Key considerations:
- Plugins can be registered at build time via the builder or at runtime via kernel.Plugins
- Multiple plugins can coexist, each with its own namespace
- Plugin names become part of the function's fully-qualified identifier
Step 3: Configure Function Calling Behavior
Set the function choice behavior to control how the AI model interacts with available plugins. Auto mode lets the model decide which functions to call and executes them automatically. Manual mode returns function call requests for the application to process.
Key considerations:
- Auto mode: model selects and invokes functions autonomously
- Manual mode: model proposes function calls, application decides whether to execute
- Required mode: forces the model to call a specific function
- None mode: disables function calling entirely
- Behavior is set via PromptExecutionSettings.FunctionChoiceBehavior
Step 4: Import OpenAPI Plugins (Optional)
Load an OpenAPI specification (JSON or YAML) and import it as a kernel plugin. Each API operation becomes a callable kernel function with parameters derived from the specification's schema.
Key considerations:
- OpenAPI specs can be loaded from files, streams, or URLs
- Operations are mapped to kernel functions with typed parameters
- Authentication can be configured per-plugin
- Plugin functions can be transformed or wrapped for customization
Step 5: Invoke Prompt With Function Calling
Send a user prompt to the AI model with function calling enabled. The model analyzes the prompt, determines which plugin functions to call, invokes them (in auto mode), and incorporates the results into its response.
Key considerations:
- The model may call multiple functions in sequence or parallel
- Function results are fed back to the model as tool messages
- The conversation loop continues until the model produces a final text response
- Function invocation filters can intercept and log each call
Step 6: Add Observability Filters (Optional)
Register function invocation filters and prompt render filters to observe and log the function calling process. Filters intercept each function invocation, providing access to the function name, arguments, and result.
Key considerations:
- IFunctionInvocationFilter intercepts before and after each function call
- IPromptRenderFilter intercepts the final rendered prompt text
- Filters are registered via dependency injection or directly on the kernel
- Token usage metadata is available in filter context