Skip to content

Set test client info#692

Merged
ezynda3 merged 3 commits intomark3labs:mainfrom
urisimchoni:set-test-client-info
Jan 12, 2026
Merged

Set test client info#692
ezynda3 merged 3 commits intomark3labs:mainfrom
urisimchoni:set-test-client-info

Conversation

@urisimchoni
Copy link
Contributor

@urisimchoni urisimchoni commented Jan 5, 2026

Description

Allow tests using mcptest to simulate client info

Type of Change

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • MCP spec compatibility implementation
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Code refactoring (no functional changes)
  • Performance improvement
  • Tests only (no functional changes)
  • Other (please describe):

Checklist

  • My code follows the code style of this project
  • I have performed a self-review of my own code
  • I have added tests that prove my fix is effective or that my feature works
  • I have updated the documentation accordingly

Additional Information

Sometimes the MCP server behavior depends slightly on the type of the MCP client. The server may use the "clientInfo" object that is sent as part of the "initialize" message. This PR adds the testing capability to mcptest, to set the clientInfo field sent by the test client to the tested server.

Summary by CodeRabbit

  • New Features

    • Servers can be preconfigured with client identity information that is propagated at startup.
    • Tools can access client identity during execution, enabling context-aware responses.
  • Tests

    • Added tests verifying client identity propagation through server startup and tool invocation.

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Jan 5, 2026

Walkthrough

Adds server-side clientInfo support: a new exported clientInfo field and SetClientInfo method on mcptest Server; the value is injected into MCP initialize requests. A new test verifies clientInfo is available during tool invocation.

Changes

Cohort / File(s) Summary
Server implementation
mcptest/mcptest.go
Added exported clientInfo mcp.Implementation field to Server; added SetClientInfo(info mcp.Implementation) method; sets initReq.Params.ClientInfo = s.clientInfo during MCP initialization (Start path).
Tests
mcptest/mcptest_test.go
Added TestSimulateClientInfo which configures server clientInfo as "test-client", starts the server, invokes a registered tool that reads client info from request context, and asserts the greeting includes the client name.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

🚥 Pre-merge checks | ✅ 2 | ❌ 1
❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely summarizes the main change: adding the capability to set test client info in the mcptest package.
Description check ✅ Passed The description covers all required sections with adequate detail: a clear description of the feature, appropriate type of change selections, completed checklist items, and contextual information explaining the purpose.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing touches
  • 📝 Generate docstrings

📜 Recent review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f379598 and 4742c41.

📒 Files selected for processing (2)
  • mcptest/mcptest.go
  • mcptest/mcptest_test.go
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Order imports: standard library first, then third-party, then local packages (goimports enforces this)
Follow Go naming conventions: exported identifiers in PascalCase; unexported in camelCase; acronyms uppercase (HTTP, JSON, MCP)
Error handling: return sentinel errors, wrap with fmt.Errorf("context: %w", err), and check with errors.Is/As
Prefer explicit types and strongly-typed structs; avoid using any except where protocol flexibility is required (e.g., Arguments any)
All exported types and functions must have GoDoc comments starting with the identifier name; avoid inline comments unless necessary
Functions that are handlers or long-running must accept context.Context as the first parameter
Ensure thread safety for shared state using sync.Mutex and document thread-safety requirements in comments
For JSON: use json struct tags with omitempty for optional fields; use json.RawMessage for flexible/deferred parsing

Files:

  • mcptest/mcptest_test.go
  • mcptest/mcptest.go
**/*_test.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*_test.go: Testing: use testify/assert and testify/require
Write table-driven tests using a tests := []struct{ name, ... } pattern
Go test files must end with _test.go

Files:

  • mcptest/mcptest_test.go
🧠 Learnings (2)
📚 Learning: 2025-04-21T21:26:32.945Z
Learnt from: octo
Repo: mark3labs/mcp-go PR: 149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.

Applied to files:

  • mcptest/mcptest_test.go
📚 Learning: 2025-06-30T07:13:17.052Z
Learnt from: ezynda3
Repo: mark3labs/mcp-go PR: 461
File: server/sampling.go:22-26
Timestamp: 2025-06-30T07:13:17.052Z
Learning: In the mark3labs/mcp-go project, the MCPServer.capabilities field is a struct value (serverCapabilities), not a pointer, so it cannot be nil and doesn't require nil checking. Only pointer fields within the capabilities struct should be checked for nil.

Applied to files:

  • mcptest/mcptest.go
🧬 Code graph analysis (1)
mcptest/mcptest.go (1)
mcp/types.go (2)
  • Implementation (587-593)
  • Params (216-216)
🔇 Additional comments (4)
mcptest/mcptest.go (3)

27-27: LGTM!

The new clientInfo field follows the existing struct pattern and uses the correct MCP type.


124-127: LGTM!

The SetClientInfo method follows the established pattern of other configuration methods (AddTools, AddPrompts, etc.) and has proper GoDoc documentation.


164-169: LGTM!

The client info is correctly propagated to the initialize request. The placement after transport.Start() and before client.Initialize() is appropriate, and the zero value fallback for unset client info is acceptable.

mcptest/mcptest_test.go (1)

415-457: LGTM!

The test is well-structured and follows the existing patterns in the file:

  • Proper setup/teardown with NewUnstartedServer and deferred Close()
  • Good defensive coding in the tool handler with nil checks for session and type assertion
  • Correctly verifies client info propagation through the MCP initialization flow
  • Reuses the existing resultToString helper

Based on learnings, the test appropriately checks error returns rather than failing directly in helper functions.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Actionable comments posted: 1

Fix all issues with AI Agents 🤖
In @mcptest/mcptest_test.go:
- Line 374: The call to srv.Start(context.TODO()) ignores its returned error and
uses context.TODO() inconsistently; change it to use the existing ctx variable
and check the error returned from srv.Start by calling err := srv.Start(ctx) and
handling it (e.g., t.Fatalf or require.NoError) similar to how
TestServerWithPrompt checks Start's error so the test fails on start failures.
📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a1b6997 and 0f5c6fb.

📒 Files selected for processing (2)
  • mcptest/mcptest.go
  • mcptest/mcptest_test.go
🧰 Additional context used
📓 Path-based instructions (2)
**/*.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*.go: Order imports: standard library first, then third-party, then local packages (goimports enforces this)
Follow Go naming conventions: exported identifiers in PascalCase; unexported in camelCase; acronyms uppercase (HTTP, JSON, MCP)
Error handling: return sentinel errors, wrap with fmt.Errorf("context: %w", err), and check with errors.Is/As
Prefer explicit types and strongly-typed structs; avoid using any except where protocol flexibility is required (e.g., Arguments any)
All exported types and functions must have GoDoc comments starting with the identifier name; avoid inline comments unless necessary
Functions that are handlers or long-running must accept context.Context as the first parameter
Ensure thread safety for shared state using sync.Mutex and document thread-safety requirements in comments
For JSON: use json struct tags with omitempty for optional fields; use json.RawMessage for flexible/deferred parsing

Files:

  • mcptest/mcptest.go
  • mcptest/mcptest_test.go
**/*_test.go

📄 CodeRabbit inference engine (AGENTS.md)

**/*_test.go: Testing: use testify/assert and testify/require
Write table-driven tests using a tests := []struct{ name, ... } pattern
Go test files must end with _test.go

Files:

  • mcptest/mcptest_test.go
🧠 Learnings (2)
📚 Learning: 2025-06-30T07:13:17.052Z
Learnt from: ezynda3
Repo: mark3labs/mcp-go PR: 461
File: server/sampling.go:22-26
Timestamp: 2025-06-30T07:13:17.052Z
Learning: In the mark3labs/mcp-go project, the MCPServer.capabilities field is a struct value (serverCapabilities), not a pointer, so it cannot be nil and doesn't require nil checking. Only pointer fields within the capabilities struct should be checked for nil.

Applied to files:

  • mcptest/mcptest.go
📚 Learning: 2025-04-21T21:26:32.945Z
Learnt from: octo
Repo: mark3labs/mcp-go PR: 149
File: mcptest/mcptest.go:0-0
Timestamp: 2025-04-21T21:26:32.945Z
Learning: In the mcptest package, prefer returning errors from helper functions rather than calling t.Fatalf() directly, giving callers flexibility in how to handle errors.

Applied to files:

  • mcptest/mcptest_test.go
🧬 Code graph analysis (2)
mcptest/mcptest.go (1)
mcp/types.go (2)
  • Implementation (581-587)
  • Params (212-212)
mcptest/mcptest_test.go (5)
mcptest/mcptest.go (1)
  • NewUnstartedServer (59-70)
mcp/tools.go (3)
  • NewTool (726-748)
  • CallToolRequest (54-58)
  • CallToolResult (40-51)
server/session.go (2)
  • ClientSessionFromContext (112-117)
  • SessionWithClientInfo (66-76)
mcp/utils.go (1)
  • NewToolResultText (271-280)
mcp/types.go (2)
  • Implementation (581-587)
  • Params (212-212)
🔇 Additional comments (5)
mcptest/mcptest.go (3)

27-27: LGTM!

The new clientInfo field follows the existing struct pattern and is appropriately placed with other configuration fields.


124-127: LGTM!

The setter method follows Go conventions and the GoDoc comment correctly starts with the identifier name as per coding guidelines.


166-166: LGTM!

The client info is correctly propagated to the initialization request, enabling the test client to identify itself to the server during the MCP handshake.

mcptest/mcptest_test.go (2)

361-370: LGTM!

The tool handler correctly demonstrates the client info retrieval pattern using ClientSessionFromContext and the type assertion to SessionWithClientInfo. The nil checks are properly handled.


371-373: LGTM!

The test correctly sets client info before starting the server and verifies the expected greeting is returned. The assertion pattern is consistent with other tests in the file.

Also applies to: 376-394

@ezynda3
Copy link
Contributor

ezynda3 commented Jan 12, 2026

@urisimchoni could you fix the merge conflict? I will merge after.

@urisimchoni
Copy link
Contributor Author

@urisimchoni could you fix the merge conflict? I will merge after.

@ezynda3 Sure, done. Sorry for not noticing that this cannot be cleanly merged.

@ezynda3 ezynda3 merged commit c49488d into mark3labs:main Jan 12, 2026
4 checks passed
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.

3 participants