chore: import upstream snapshot with attribution

2026-07-13 13:39:25 +08:00
commit db620d33df
5151 changed files with 925932 additions and 0 deletions
@@ -0,0 +1,130 @@
+---
+name: build-and-test
+description: How to build and test .NET projects in the Agent Framework repository. Use this when verifying or testing changes.
+---
+
+- Only **UnitTest** projects need to be run locally; IntegrationTests require external dependencies.
+- See `../project-structure/SKILL.md` for project structure details.
+
+## Build, Test, and Lint Commands
+
+```bash
+# From dotnet/ directory
+dotnet restore --tl:off   # Restore dependencies for all projects
+dotnet build --tl:off     # Build all projects
+dotnet test               # Run all tests
+dotnet format             # Auto-fix formatting for all projects
+
+# Build/test/format a specific project (preferred for isolated/internal changes)
+dotnet build src/Microsoft.Agents.AI.<Package> --tl:off
+dotnet test --project tests/Microsoft.Agents.AI.<Package>.UnitTests
+dotnet format src/Microsoft.Agents.AI.<Package>
+
+# Run a single test
+# Replace the filter values with the appropriate assembly, namespace, class, and method names for the test you want to run and use * as a wildcard elsewhere, e.g. "/*/*/HttpClientTests/GetAsync_ReturnsSuccessStatusCode"
+# Use `--ignore-exit-code 8` to avoid failing the build when no tests are found for some projects
+dotnet test --filter-query "/<assemblyFilter>/<namespaceFilter>/<classFilter>/<methodFilter>" --ignore-exit-code 8
+
+# Run unit tests only
+# Use `--ignore-exit-code 8` to avoid failing the build when no tests are found for integration test projects
+dotnet test --filter-query "/*UnitTests*/*/*/*" --ignore-exit-code 8
+```
+
+Use `--tl:off` when building to avoid flickering when running commands in the agent.
+
+## Speeding Up Builds and Testing
+
+The full solution is large. Use these shortcuts:
+
+| Change type | What to do |
+|-------------|------------|
+| Isolated/Internal logic | Build only the affected project and its `*.UnitTests` project. Fix issues, then build the full solution and run all unit tests. |
+| Public API surface | Build the full solution and run all unit tests immediately. |
+
+Example: Building a single code project for all target frameworks
+
+```bash
+# From dotnet/ directory
+dotnet build ./src/Microsoft.Agents.AI.Abstractions
+```
+
+Example: Building a single code project for just .NET 10.
+
+```bash
+# From dotnet/ directory
+dotnet build ./src/Microsoft.Agents.AI.Abstractions -f net10.0
+```
+
+Example: Running tests for a single project using .NET 10.
+
+```bash
+# From dotnet/ directory
+dotnet test --project ./tests/Microsoft.Agents.AI.Abstractions.UnitTests -f net10.0
+```
+
+Example: Running a single test in a specific project using .NET 10.
+Provide the full namespace, class name, and method name for the test you want to run:
+
+```bash
+# From dotnet/ directory
+dotnet test --project ./tests/Microsoft.Agents.AI.Abstractions.UnitTests -f net10.0 --filter-query "/*/Microsoft.Agents.AI.Abstractions.UnitTests/AgentRunOptionsTests/CloningConstructorCopiesProperties"
+```
+
+### Multi-target framework tip
+
+Most projects target multiple .NET frameworks. If the affected code does **not** use `#if` directives for framework-specific logic, pass `-f net10.0` to speed up building and testing.
+
+### Package Restore tip
+
+`dotnet build` will try and restore packages for all projects on each build, which can be slow.
+Unless packages have been changed, or it's the first time building the solution, add `--no-restore` to the build command to skip this step and speed up builds.
+
+Just remember to run `dotnet restore` after pulling changes, making changes to project references, or when building for the first time.
+
+### Testing on Linux tip
+
+Unit tests target both .NET Framework as well as .NET Core. When running on Linux, only the .NET Core tests can be run, as .NET Framework is not supported on Linux.
+
+To run only the .NET Core tests, use the `-f net10.0` option with `dotnet test`.
+
+### Microsoft Testing Platform (MTP)
+
+Tests use the [Microsoft Testing Platform](https://learn.microsoft.com/dotnet/core/testing/unit-testing-platform-intro) via xUnit v3. Key differences from the legacy VSTest runner:
+
+- **`dotnet test` requires `--project`** to specify a test project directly (positional arguments are no longer supported).
+- **Test output** uses the MTP format (e.g., `[✓112/x0/↓0]` progress and `Test run summary: Passed!`).
+- **TRX reports** use `--report-xunit-trx` instead of `--logger trx`.
+- **Code coverage** uses `Microsoft.Testing.Extensions.CodeCoverage` with `--coverage --coverage-output-format cobertura`.
+- **Running a test project directly** is supported via `dotnet run --project <test-project>`. This bypasses the `dotnet test` infrastructure and runs the test executable directly with the MTP command line.
+
+- **Running tests across the solution** with a filter may cause some projects to match zero tests, which MTP treats as a failure (exit code 8). Use `--ignore-exit-code 8` to suppress this:
+
+```bash
+# Run all unit tests across the solution, ignoring projects with no matching tests
+dotnet test --solution ./agent-framework-dotnet.slnx --no-build -f net10.0 --ignore-exit-code 8
+```
+
+- **Running tests with `--solution` for a specific TFM** requires all projects in the solution to support that TFM. Not all projects target every framework (e.g., some are `net10.0`-only). Use `./dotnet/eng/scripts/New-FilteredSolution.ps1` to generate a filtered solution:
+
+```powershell
+# Generate a filtered solution for net472 and run tests
+$filtered = ./dotnet/eng/scripts/New-FilteredSolution.ps1 -Solution dotnet/agent-framework-dotnet.slnx -TargetFramework net472
+dotnet test --solution $filtered --no-build -f net472 --ignore-exit-code 8
+
+# Exclude samples and keep only unit test projects
+./dotnet/eng/scripts/New-FilteredSolution.ps1 -Solution dotnet/agent-framework-dotnet.slnx -TargetFramework net10.0 -ExcludeSamples -TestProjectNameFilter "*UnitTests*" -OutputPath dotnet/filtered-unit.slnx
+```
+
+```bash
+# Run tests via dotnet test (uses MTP under the hood)
+dotnet test --project ./tests/Microsoft.Agents.AI.UnitTests -f net10.0
+
+# Run tests with code coverage (Cobertura format)
+dotnet test --project ./tests/Microsoft.Agents.AI.UnitTests -f net10.0 --coverage --coverage-output-format cobertura --coverage-settings ./tests/coverage.runsettings
+
+# Run tests directly via dotnet run (MTP native command line)
+dotnet run --project ./tests/Microsoft.Agents.AI.UnitTests -f net10.0
+
+# Show MTP command line help
+dotnet run --project ./tests/Microsoft.Agents.AI.UnitTests -f net10.0 -- -?
+```
@@ -0,0 +1,31 @@
+---
+name: project-structure
+description: Explains the project structure of the agent-framework .NET solution
+---
+
+# Agent Framework .NET Project Structure
+
+```
+dotnet/
+├── src/
+│   ├── Microsoft.Agents.AI/                      # Core AI agent implementations
+│   ├── Microsoft.Agents.AI.Abstractions/         # Core AI agent abstractions
+│   ├── Microsoft.Agents.AI.A2A/                  # Agent-to-Agent (A2A) provider
+│   ├── Microsoft.Agents.AI.OpenAI/               # OpenAI provider
+│   ├── Microsoft.Agents.AI.Foundry/               # Microsoft Foundry Agents (v2) provider
+│   ├── Microsoft.Agents.AI.AzureAI.Persistent/   # Legacy Microsoft Foundry Agents (v1) provider
+│   ├── Microsoft.Agents.AI.Anthropic/            # Anthropic provider
+│   ├── Microsoft.Agents.AI.Workflows/            # Workflow orchestration
+│   └── ...                                       # Other packages
+├── samples/                                      # Sample applications
+└── tests/                                        # Unit and integration tests
+```
+
+## Main Folders
+
+| Folder | Contents |
+|--------|----------|
+| `src/` | Source code projects |
+| `tests/` | Test projects — named `<Source-Code-Project>.UnitTests` or `<Source-Code-Project>.IntegrationTests` |
+| `samples/` | Sample projects |
+| `src/Shared`, `src/LegacySupport` | Shared code files included by multiple source code projects (see README.md files in these folders or their subdirectories for instructions on how to include them in a project) |
@@ -0,0 +1,116 @@
+---
+name: pull-requests
+description: >
+  Guidance for creating pull requests and handling PR review comments in the
+  Agent Framework repository. Use this when writing a PR description (filling out
+  the PR template) or when responding to and resolving review comments on an
+  existing PR.
+---
+
+# Pull Request Workflow
+
+This skill covers two tasks: (1) writing a high-quality PR description, and
+(2) handling review comments on an existing PR.
+
+## 1. Writing the PR description
+
+Always follow the repository PR template at
+[`.github/pull_request_template.md`](../../../../.github/pull_request_template.md). Keep its
+exact structure and headings. Fill every section:
+
+### `### Motivation & Context`
+Explain *why* the change is needed: the problem it solves and the scenario it
+contributes to. Describe the net change relative to `main` — this is implied, so
+do **not** spell out "vs main" explicitly.
+
+### `### Description & Review Guide`
+Describe the changes, the overall approach, and the design. Answer the three
+prompts:
+- **What are the major changes?**
+- **What is the impact of these changes?**
+- **What do you want reviewers to focus on?** — This item is for **human
+  reviewers only**. Automated/AI reviewers must ignore it and review the entire
+  change rather than narrowing scope to it.
+
+### `### Related Issue`
+Link the issue the PR fixes using a GitHub closing keyword (`Fixes #123` /
+`Closes #123`) so it closes automatically on merge. A PR with no linked issue may
+be closed regardless of how valid the change is. Before opening, confirm there is
+no other open PR for the same issue; if there is, explain how this PR differs.
+
+### `### Contribution Checklist`
+Check every item that applies. For the breaking-change item:
+- Leave **"This is not a breaking change."** checked for the common case.
+- If the change **is** breaking, add the `breaking change` label **or** put
+  `[BREAKING]` in the title prefix, before or after a language prefix such as
+  `Python:` or `.NET:` — workflows keep the label and the title prefix in sync
+  automatically (see `.github/workflows/label-title-prefix.yml` and
+  `.github/workflows/label-pr.yml`).
+
+### Do not
+- Do **not** add ad-hoc sections such as "Validation" or "Tests run"; CI/CD and
+  the checklist already cover validation status.
+- Do **not** remove or reorder the template's headings.
+
+### Creating the PR
+Open new PRs as **drafts** until they are ready for review. Example:
+
+```bash
+gh pr create --repo microsoft/agent-framework --base main \
+  --head <your-fork-owner>:<branch> --draft \
+  --title "<concise title>" --body "<body following the template>"
+```
+
+## 2. Handling review comments
+
+When a PR receives review comments, follow this sequence — **do not start editing
+code before the user has reviewed the plan**:
+
+1. **Review the comments.** Read every review comment and thread on the PR,
+   including inline code comments and general review summaries.
+2. **Make a plan.** Produce a concrete plan describing how each comment will be
+   addressed (or why it should not be, with reasoning).
+3. **Let the user review the plan.** Present the plan and wait for the user's
+   approval or adjustments before implementing anything.
+4. **Implement.** Make the agreed changes.
+5. **Reply to every comment.** Add a reply to **all** comments explaining how it
+   was addressed (or the agreed outcome) — leave none unanswered.
+6. **Resolve resolved threads.** Mark a review thread as resolved only when the
+   comment has actually been addressed.
+
+### Useful commands
+
+List review comments and threads:
+
+```bash
+# Inline review comments
+gh api repos/{owner}/{repo}/pulls/{pr}/comments
+
+# Review threads with resolution state (GraphQL)
+gh api graphql -f query='
+  query($owner:String!,$repo:String!,$pr:Int!){
+    repository(owner:$owner,name:$repo){
+      pullRequest(number:$pr){
+        reviewThreads(first:100){
+          nodes{ id isResolved comments(first:50){ nodes{ id body author{login} } } }
+        }
+      }
+    }
+  }' -F owner={owner} -F repo={repo} -F pr={pr}
+```
+
+Reply to an inline review comment:
+
+```bash
+gh api repos/{owner}/{repo}/pulls/{pr}/comments/{comment_id}/replies \
+  -f body="Addressed in <commit>: <explanation>"
+```
+
+Resolve a review thread (needs the thread node id from the GraphQL query above):
+
+```bash
+gh api graphql -f query='
+  mutation($threadId:ID!){
+    resolveReviewThread(input:{threadId:$threadId}){ thread{ isResolved } }
+  }' -F threadId={thread_id}
+```
@@ -0,0 +1,82 @@
+---
+name: verify-dotnet-samples
+description: How to build, run and verify the .NET sample projects in the Agent Framework repository. Use this when a user wants to verify that the samples still function as expected.
+---
+
+# Verifying .NET Sample Projects
+
+## Sample Pre-requisites
+
+We should only support verifying samples that:
+1. Use environment variables for configuration.
+2. Have no complex setup requirements, e.g., where multiple applications need to be run together, or where we need to launch a browser, etc.
+
+Always report to the user which samples were run and which were not, and why.
+
+## Verifying a sample
+
+Samples should be verified to ensure that they actually work as intended and that their output matches what is expected.
+For each sample that is run, output should be produced that shows the result and explains the reasoning about what output
+was expected, what was produced, and why it didn't match what the sample was expected to produce.
+
+Steps to verify a sample:
+1. Read the code for the sample
+1. Check what environment variables are required for the sample
+1. Check if each environment variable has been set
+1. If there are any missing, give the user a list of missing environment variables to set and terminate
+1. Summarize what the expected output of the sample should be
+1. Run the sample
+1. Show the user any output from the sample run as it gets produced, so that they can see the run progress
+1. Check the output of the run against expectations
+1. After running all requested samples, produce output for each sample that was verified:
+  1. If expectations were matched, output the following:
+     ```text
+     [Sample Name] Succeeded
+     ```
+  1. If expectations were not matched, output the following:
+     ```text
+     [Sample Name] Failed
+     Actual Output:
+     [What the sample produced]
+     Expected Output:
+     [Explanation of what was expected and why the actual output didn't match expectations]
+     ```
+
+## Environment Variables
+
+Most samples use environment variables to configure settings.
+
+```csharp
+var endpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT") ?? throw new InvalidOperationException("AZURE_OPENAI_ENDPOINT is not set.");
+var deploymentName = Environment.GetEnvironmentVariable("AZURE_OPENAI_DEPLOYMENT_NAME") ?? "gpt-4o-mini";
+```
+
+To run a sample, the environment variables should be set first.
+Before running a sample, check whether each environment variable in the sample has a value and
+then give the user a list of environment variables to set.
+
+You can provide the user some examples of how to set the variables like this:
+
+```bash
+export AZURE_OPENAI_ENDPOINT="https://my-openai-instance.openai.azure.com/"
+export AZURE_OPENAI_DEPLOYMENT_NAME="gpt-4o-mini"
+```
+
+To check if a variable has a value use e.g.:
+
+```bash
+echo $AZURE_OPENAI_ENDPOINT
+```
+
+## How to Run a Sample (General Pattern)
+
+```bash
+cd dotnet/samples/<category>/<sample-dir>
+dotnet run
+```
+
+For multi-targeted projects (e.g., Durable console apps), specify the framework:
+
+```bash
+dotnet run --framework net10.0
+```
@@ -0,0 +1,227 @@
+---
+name: verify-samples-tool
+description: How to use the verify-samples tool to run, verify, and manage sample definitions in the Agent Framework repository. Use this when adding, updating, or running sample verification.
+---
+
+# verify-samples Tool
+
+The `verify-samples` project (`dotnet/eng/verify-samples/`) is an automated tool that runs sample projects and verifies their output using deterministic checks and AI-powered verification.
+
+## Running verify-samples
+
+**Important:** By default, samples must be pre-built before running verify-samples. Build the solution first, or pass `--build` to build samples during the run:
+
+```bash
+cd dotnet
+dotnet build agent-framework-dotnet.slnx -f net10.0
+```
+
+Then run verify-samples:
+
+```bash
+# Run all samples across all categories
+dotnet run --project eng/verify-samples -- --log results.log --csv results.csv
+
+# Run a specific category
+dotnet run --project eng/verify-samples -- --category 02-agents --log results.log
+
+# Run specific samples by name
+dotnet run --project eng/verify-samples -- Agent_Step02_StructuredOutput Agent_Step09_AsFunctionTool
+
+# Control parallelism (default 8)
+dotnet run --project eng/verify-samples -- --parallel 8 --log results.log
+
+# Build samples during run (skips the need for a prior build step)
+# This may cause build conflicts as multiple samples are built in parallel, so use with caution
+dotnet run --project eng/verify-samples -- --build --log results.log
+
+# Combine options
+dotnet run --project eng/verify-samples -- --category 03-workflows --parallel 4 --log results.log --csv results.csv --md results.md
+```
+
+### Required Environment Variables
+
+The tool itself needs:
+- `AZURE_OPENAI_ENDPOINT` — for the AI verification agent
+- `AZURE_OPENAI_DEPLOYMENT_NAME` (optional, defaults to `gpt-5-mini`)
+
+Individual samples require their own env vars (e.g., `AZURE_AI_PROJECT_ENDPOINT`). The tool automatically checks and skips samples with missing env vars.
+
+### Output Files
+
+- `--log results.log` — detailed per-sample log with stdout/stderr, AI reasoning, and a summary
+- `--csv results.csv` — tabular summary with Sample, ProjectPath, Status, FailedChecks, and Failures columns
+- `--md results.md` — Markdown summary with results table and collapsible failure details (suitable for GitHub PR comments)
+
+## Sample Categories
+
+Definitions are in the `dotnet/eng/verify-samples/` directory:
+
+| Category | Config File | Registered Key |
+|----------|-------------|----------------|
+| 01-get-started | `GetStartedSamples.cs` | `01-get-started` |
+| 02-agents | `AgentsSamples.cs` | `02-agents` |
+| 03-workflows | `WorkflowSamples.cs` | `03-workflows` |
+
+Categories are registered in `VerifyOptions.cs` in the `s_sampleSets` dictionary.
+
+## SampleDefinition Properties
+
+Each sample is defined as a `SampleDefinition` in the appropriate config file. Key properties:
+
+```csharp
+new SampleDefinition
+{
+    // Required: Display name for the sample
+    Name = "Agent_Step02_StructuredOutput",
+
+    // Required: Relative path from dotnet/ to the sample project directory
+    ProjectPath = "samples/02-agents/Agents/Agent_Step02_StructuredOutput",
+
+    // Environment variables the sample requires (throws if missing)
+    RequiredEnvironmentVariables = ["AZURE_OPENAI_ENDPOINT"],
+
+    // Environment variables with defaults that would prompt on console if unset
+    OptionalEnvironmentVariables = ["AZURE_OPENAI_DEPLOYMENT_NAME"],
+
+    // Skip this sample with a reason (for structural issues only)
+    SkipReason = null, // or "Requires external service X."
+
+    // Deterministic checks: substrings that must appear in stdout
+    MustContain = ["=== Section Header ==="],
+
+    // Substrings that must NOT appear in stdout
+    MustNotContain = [],
+
+    // If true, only MustContain checks are used (no AI verification)
+    IsDeterministic = false,
+
+    // AI verification: natural-language descriptions of expected output
+    // Each entry describes one aspect to verify independently
+    ExpectedOutputDescription =
+    [
+        "The output should show structured person information with Name, Age, and Occupation fields.",
+        "The output should not contain error messages or stack traces.",
+    ],
+
+    // Stdin inputs to feed to the sample (for interactive samples)
+    Inputs = ["Y", "Y", "Y"],
+
+    // Delay between stdin inputs in ms (default 2000, increase for LLM calls between inputs)
+    InputDelayMs = 3000,
+}
+```
+
+## How to Add a New Sample Definition
+
+1. **Check the sample's Program.cs** to understand:
+   - What environment variables it reads (look for `GetEnvironmentVariable`)
+   - Whether it needs stdin input (look for `Console.ReadLine`, `Application.GetInput`)
+   - Whether it has an external loop (look for `EXIT` patterns in YAML workflows)
+   - What output it produces (section headers, markers, expected behavior)
+   - Whether it exits on its own or runs as a server
+
+2. **Choose the right verification strategy:**
+   - **Deterministic** (`IsDeterministic = true`): Use `MustContain` for samples with fixed output strings. No AI verification.
+   - **AI-verified** (default): Use `ExpectedOutputDescription` with semantic descriptions. Write expectations that are flexible enough for non-deterministic LLM output.
+   - **Both**: Use `MustContain` for fixed markers AND `ExpectedOutputDescription` for LLM-generated content.
+
+3. **Set `SkipReason` only for structural issues:**
+   - Web servers that don't exit
+   - Multi-process client/server architectures
+   - Samples requiring external infrastructure (MCP servers you can't reach, Docker, etc.)
+   - Do NOT skip for missing env vars — the tool checks those dynamically.
+
+4. **For interactive samples, provide `Inputs`:**
+   - Samples using `Application.GetInput(args)` need one initial input
+   - Samples with `Console.ReadLine()` approval loops need `"Y"` inputs
+   - YAML workflows with `externalLoop` need `"EXIT"` as the last input
+   - Set `InputDelayMs` to 3000-8000ms for samples with LLM calls between inputs
+
+5. **Add the definition** to the appropriate config file (e.g., `AgentsSamples.cs`) in the `All` list.
+
+6. **Register new categories** (if needed) in `VerifyOptions.cs` `s_sampleSets` dictionary.
+
+### Writing Good ExpectedOutputDescription
+
+- Write descriptions that are **semantically flexible** — LLM output varies between runs
+- Each array entry should describe **one independent aspect** to verify
+- Always include `"The output should not contain error messages or stack traces."` as the last entry
+- Avoid exact wording expectations — use "should mention", "should contain information about", "should show"
+- Bad: `"The output should say 'The weather in Amsterdam is cloudy with a high of 15°C'"`
+- Good: `"The output should contain weather information about Amsterdam mentioning cloudy weather with a high of 15°C."`
+
+### Example: Simple LLM Sample
+
+```csharp
+new SampleDefinition
+{
+    Name = "Agent_With_AzureOpenAIChatCompletion",
+    ProjectPath = "samples/02-agents/AgentProviders/azure/Agent_With_AzureOpenAIChatCompletion",
+    RequiredEnvironmentVariables = ["AZURE_OPENAI_ENDPOINT"],
+    OptionalEnvironmentVariables = ["AZURE_OPENAI_DEPLOYMENT_NAME"],
+    ExpectedOutputDescription =
+    [
+        "The output should contain a joke about a pirate.",
+        "The output should not contain error messages or stack traces.",
+    ],
+},
+```
+
+### Example: Deterministic Sample
+
+```csharp
+new SampleDefinition
+{
+    Name = "Workflow_Visualization",
+    ProjectPath = "samples/03-workflows/Visualization",
+    IsDeterministic = true,
+    MustContain = ["Generating workflow visualization...", "Mermaid string:", "DiGraph string:"],
+    ExpectedOutputDescription = ["The output should show workflow visualization in Mermaid and DiGraph formats."],
+},
+```
+
+### Example: Interactive Sample with Approval Loop
+
+```csharp
+new SampleDefinition
+{
+    Name = "FoundryAgent_Hosted_MCP",
+    ProjectPath = "samples/02-agents/ModelContextProtocol/FoundryAgent_Hosted_MCP",
+    RequiredEnvironmentVariables = ["AZURE_AI_PROJECT_ENDPOINT"],
+    OptionalEnvironmentVariables = ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
+    Inputs = ["Y", "Y", "Y", "Y", "Y"],
+    InputDelayMs = 5000,
+    ExpectedOutputDescription = ["The output should show an agent using the Microsoft Learn MCP tool with approval prompts."],
+},
+```
+
+### Example: Declarative Workflow with External Loop
+
+```csharp
+new SampleDefinition
+{
+    Name = "Workflow_Declarative_FunctionTools",
+    ProjectPath = "samples/03-workflows/Declarative/FunctionTools",
+    RequiredEnvironmentVariables = ["AZURE_AI_PROJECT_ENDPOINT"],
+    OptionalEnvironmentVariables = ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
+    Inputs = ["What are today's specials?", "EXIT"],
+    InputDelayMs = 8000,
+    ExpectedOutputDescription = ["The output should show a workflow calling function tools to answer a question about restaurant specials."],
+},
+```
+
+### Example: Skipped Sample
+
+```csharp
+new SampleDefinition
+{
+    Name = "Agent_MCP_Server",
+    ProjectPath = "samples/02-agents/ModelContextProtocol/Agent_MCP_Server",
+    RequiredEnvironmentVariables = ["AZURE_OPENAI_ENDPOINT"],
+    OptionalEnvironmentVariables = ["AZURE_OPENAI_DEPLOYMENT_NAME"],
+    SkipReason = "Runs as an MCP stdio server that does not exit on its own.",
+},
+```
+
+