Skip to content

Strengthen mcp-csharp-test with prescriptive MCP-specific steps#940

Closed
leslierichardson95 wants to merge 1 commit into
mainfrom
leslierichardson95/strengthen-mcp-csharp-test
Closed

Strengthen mcp-csharp-test with prescriptive MCP-specific steps#940
leslierichardson95 wants to merge 1 commit into
mainfrom
leslierichardson95/strengthen-mcp-csharp-test

Conversation

@leslierichardson95

Copy link
Copy Markdown
Contributor

What

Strengthens mcp-csharp-test with prescriptive, MCP-specific guidance so it helps strong models, not just weak ones.

Why

The cross-family skills-eval (#889) rated this skill high-impact (0.65) but STRENGTHEN 0/5 — it misses both frontier models because it "assumes context they solve unaided." The body largely showed generic xUnit patterns a frontier model already knows, so a skilled run tied with baseline.

Changes (kept lean — the skill is already token-efficient)

  • Default integration tests to the SDK's in-memory ClientServerTestBase instead of spawning dotnet run via StdioClientTransport; reserve the process-spawning transport for a single end-to-end smoke test. (Per-fixture process spawning is the top cause of flaky/hanging integration tests — the skill's own Pitfalls section calls this out.)
  • Add an MCP-specific quality assertion: every tool must expose a non-empty Description (MCP clients rely on descriptions to choose tools) — a check frontier models don't write by default.
  • Add matching Validation checklist items.

Verification

skill-validator check runs in CI. Recommend a cross-family eval re-run (-f skills="mcp-csharp-test" -f executors="opus,gpt" -f runs=5; prior avgN was ~2.8, so use more runs).

Refs #889


Moved from fork branch to the primary dotnet/skills repo; supersedes #936.

The cross-family eval (#889) rated mcp-csharp-test high-impact (0.65) but
STRENGTHEN 0/5 — it misses frontier models because it 'assumes context
they solve unaided' (generic xUnit testing). Add opinionated,
MCP-specific steps that change behavior even for strong models, while
keeping the skill token-efficient:

- Default integration tests to the SDK's in-memory ClientServerTestBase;
  reserve process-spawning StdioClientTransport for one E2E smoke test
  (spawning dotnet run per fixture is the top cause of flaky/hanging tests)
- Add an MCP-specific quality assertion: every tool must expose a
  non-empty Description (MCP clients rely on it to choose tools)
- Add matching Validation checklist items

Refs #889

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 6a8ce111-58e5-48a7-9f7f-8de972bdc693
@github-actions

Copy link
Copy Markdown
Contributor

Skill Coverage Report

Plugin Skill Covered Coverage
dotnet-ai mcp-csharp-test 0/20 0%
Uncovered: dotnet-ai/mcp-csharp-test
  • [Validation] Unit tests cover all tool methods, including edge cases (line 172)
  • [Validation] Integration tests use in-memory ClientServerTestBase (process-spawning limited to one E2E smoke test) (line 173)
  • [Validation] Integration tests verify tool listing via ListToolsAsync() (line 174)
  • [Validation] Every tool exposes a non-empty Description (asserted in a test) (line 175)
  • [Validation] Integration tests verify tool invocation via CallToolAsync() (line 176)
  • [Validation] All tests pass: dotnet test (line 177)
  • [Validation] Tests run in CI without manual setup (line 178)
  • [Pitfall] Integration test hangs on CreateAsync (line 184)
  • [Pitfall] StdioClientTransport not finding project (line 185)
  • [Pitfall] Tests pass locally but fail in CI (line 186)
  • [Pitfall] Mocking HttpClient is awkward (line 187)
  • [Pitfall] Full test suite runs are slow (line 188)
  • [WorkflowStep] Step 1: Create the test project (line 42)
  • [WorkflowStep] Step 2: Write unit tests for tool methods (line 53)
  • [WorkflowStep] Step 3: Write integration tests with MCP client (line 94)
  • [WorkflowStep] Step 4: Run tests (line 148)
  • [WorkflowStep] Step 5: Write evaluations (line 161)
  • [CodePattern] [Theory] (line 57)
  • [CodePattern] [InlineData] (line 57)
  • [CodePattern] [Fact] (line 57)

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Strengthens the mcp-csharp-test skill content to be more prescriptive and MCP-specific, aiming to improve skilled-run behavior (especially for stronger models) by emphasizing deterministic in-memory integration testing and adding a quality gate around tool descriptions.

Changes:

  • Adds guidance to default integration tests to in-memory ClientServerTestBase and limit StdioClientTransport to a single E2E smoke test.
  • Adds an MCP-specific integration test assertion that every tool exposes a non-empty Description.
  • Updates the Validation checklist to reflect the new testing guidance and description requirement.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment on lines +96 to 100
Test the full MCP protocol through a real MCP client.

> **Default to in-memory testing.** Use the SDK's `ClientServerTestBase` (see [references/test-patterns.md](references/test-patterns.md)) — it wires client and server in-process, so tests are fast and deterministic with no spawned process. Reserve the process-spawning `StdioClientTransport` below for **one** end-to-end smoke test, not your whole suite — spawning `dotnet run` per fixture is the #1 cause of flaky, hanging integration tests.

```csharp
Comment on lines +131 to +132
var tools = await _client.ListToolsAsync();
tools.Should().OnlyContain(t => !string.IsNullOrWhiteSpace(t.Description));
@leslierichardson95

Copy link
Copy Markdown
Contributor Author

Superseded by #943, which retires this skill (and the rest of the mcp-csharp-* family) per the #889 eval + telemetry review. Closing as obsolete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants