Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AutoFixture MCP Server Show me the quick start guide for AutoFixture"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides comprehensive documentation and usage examples for the AutoFixture testing library. This server runs in a Docker container and can be easily integrated with VSCode, Cursor, or Claude Desktop.
Quick Start Guide: Get up and running with AutoFixture basics
Method Search: Search for specific AutoFixture methods and their usage
Class Information: Detailed documentation for core AutoFixture classes
Package Information: NuGet package details for all AutoFixture extensions
Usage Patterns: Common patterns and code examples
Best Practices: Recommended approaches for using AutoFixture
GitHub Documentation: Fetch latest docs directly from the repository
Related MCP server: MCP Reference Server
get_quick_start: Get AutoFixture quick start guide and basic usage examples
search_methods: Search for AutoFixture methods (e.g., 'Create', 'Build', 'Freeze')
get_class_info: Get detailed information about classes like 'Fixture' or 'IFixture'
get_packages: List AutoFixture NuGet packages by category (core/mocking/testing/all)
get_usage_pattern: Get common usage patterns (e.g., 'customizing', 'automaq', 'xunit')
get_best_practices: Get AutoFixture best practices and recommendations
fetch_github_docs: Fetch latest documentation from GitHub (README, cheatsheet, FAQ)
Docker installed on your system
Node.js 20+ (for local development)
VSCode, Cursor, or Claude Desktop
Build the Docker image:
docker build -t autofixture-mcp-server:latest .Test the server:
docker run --rm -i autofixture-mcp-server:latestdocker-compose up -dOpen Cursor settings (Cmd+Shift+P → "Preferences: Open User Settings (JSON)")
Add the MCP server configuration:
{
"mcp": {
"servers": {
"autofixture": {
"command": "/Users/admin/dev/mcp/mcp-wrapper.sh"
}
}
}
}Or use the provided config file:
# Copy the configuration
cat cursor-mcp-config.json
# Add to your Cursor settingsInstall the Claude Code extension
Open your MCP configuration file:
On macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
On Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
On Windows: %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json
Add the server configuration:
{
"mcpServers": {
"autofixture": {
"command": "/Users/admin/dev/mcp/mcp-wrapper.sh",
"args": [],
"env": {}
}
}
}Open Claude Desktop settings:
On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%\Claude\claude_desktop_config.json
On Linux: ~/.config/Claude/claude_desktop_config.json
Add the server configuration:
{
"mcpServers": {
"autofixture": {
"command": "/Users/admin/dev/mcp/mcp-wrapper.sh",
"args": [],
"env": {}
}
}
}Restart Claude Desktop
If you want to develop or modify the server locally:
Install dependencies:
npm installBuild the project:
npm run buildRun locally (without Docker):
npm startDevelopment mode with auto-rebuild:
npm run devOnce integrated, you can use the MCP server in your conversations:
User: "Use the autofixture MCP to show me how to get started with AutoFixture"
AI: [Calls get_quick_start tool and provides quick start guide]User: "Search for methods related to creating objects in AutoFixture"
AI: [Calls search_methods with query "create" and shows available methods]User: "Show me how to use AutoFixture with xUnit"
AI: [Calls get_usage_pattern with pattern "xunit" and provides examples]User: "What AutoFixture packages are available for mocking?"
AI: [Calls get_packages with category "mocking" and lists all mocking packages]mcp-config.json: Generic MCP configuration
cursor-mcp-config.json: Cursor-specific configuration
claude_desktop_config.json: Claude Desktop configuration
docker-compose.yml: Docker Compose configuration
mcp-wrapper.sh: Shell script wrapper for Docker integration
Ensure Docker is running: docker ps
Check Docker logs: docker logs autofixture-mcp-server
Rebuild the image: docker build -t autofixture-mcp-server:latest .
chmod +x mcp-wrapper.shRestart the editor after adding configuration
Check that the wrapper script path is absolute
Verify Docker is installed: docker --version
# Run the wrapper script directly
./mcp-wrapper.sh
# Or use Docker directly
docker run --rm -i autofixture-mcp-server:latest.
├── src/
│ └── index.ts # Main MCP server implementation
├── dist/ # Compiled JavaScript (generated)
├── Dockerfile # Docker image configuration
├── docker-compose.yml # Docker Compose setup
├── mcp-wrapper.sh # Shell wrapper for Docker
├── package.json # Node.js dependencies
├── tsconfig.json # TypeScript configuration
├── mcp-config.json # Generic MCP config
├── cursor-mcp-config.json # Cursor-specific config
├── claude_desktop_config.json # Claude Desktop config
└── README.md # This fileThe server is built using:
TypeScript: Type-safe server implementation
@modelcontextprotocol/sdk: Official MCP SDK
axios: HTTP client for fetching GitHub documentation
cheerio: HTML parsing (for future enhancements)
Docker: Containerization for easy deployment
Feel free to extend the server with additional tools:
Add new tool definitions in the ListToolsRequestSchema handler
Implement the tool logic in the CallToolRequestSchema handler
Rebuild the Docker image
MIT
1.0.0
Built with MCP for enhanced AI-assisted development with AutoFixture.
Fetch latest documentation from AutoFixture GitHub repository
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Documentation topic to fetch (e.g., 'README', 'cheatsheet', 'faq') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It merely states 'fetch', implying a read operation, but reveals no details about response format, error handling, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the core purpose. While efficient, it could be structured to include usage context or sibling differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is incomplete. It does not explain the return format or provide enough context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single parameter 'topic'. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and the resource 'latest documentation from AutoFixture GitHub repository'. However, it does not differentiate from sibling tools like get_best_practices or get_quick_start, which handle specific documentation topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the specific sibling tools. The agent receives no information about context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AutoFixture best practices and recommendations
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It only states the tool 'gets' data, but does not describe the return format, whether it is cached, or if there are any side effects. The lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. While very brief, it covers the essential purpose for a parameterless tool. It could be slightly improved by adding a note on output format without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is the sole source of context. It provides the basic purpose but omits details about the nature of the recommendations (e.g., list, markdown, length). This is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds no parameter meaning since none exist, but the baseline for zero parameters is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'AutoFixture best practices and recommendations', using a specific verb and resource. It distinguishes itself from sibling tools like get_usage_pattern or fetch_github_docs, which focus on different aspects of AutoFixture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of typical scenarios, prerequisites, or when not to use it, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific AutoFixture class
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | Name of the class (e.g., 'Fixture', 'IFixture') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose whether the operation is read-only, any authentication needs, or what 'detailed information' includes. The minimal description fails to convey behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Communicates the essential purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is adequate but leaves out what information is returned. Given the context, a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter with an example. The description adds no extra meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), the resource (detailed information about an AutoFixture class), and distinguishes from sibling tools like fetch_github_docs or get_best_practices, which target different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided, but the purpose is clear enough for an agent to infer usage for retrieving class details. The lack of exclusions or comparisons limits score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get list of AutoFixture NuGet packages and their purposes
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Package category: 'core', 'mocking', 'testing', or 'all' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear full weight. It only says 'Get list,' with no disclosure about whether it involves network calls, caching, or any other behaviors. This is insufficient for a tool with no safety annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded and efficient, though it could benefit from minor additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, no output schema), the description is adequate but lacks any mention of return format or read-only implications. It meets minimum viability but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the schema already defines the enum values. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a list of AutoFixture NuGet packages with their purposes, using a specific verb ('Get') and resource. It distinguishes from siblings like fetch_github_docs or get_best_practices by focusing on package listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_class_info or search_methods. No when-not or explicit context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get AutoFixture quick start guide and basic usage examples
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention whether the tool is read-only, its return format, error handling, or any side effects. The description is minimal and does not reveal behavioral traits beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that conveys the purpose without any wasted words. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is adequate but lacks context about the format of the guide, whether it's markdown or plain text, or any prerequisites. For a simple retrieval tool, it is minimally complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% by default. The description adds no parameter information, but none is needed since there are no parameters. Baseline for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a quick start guide and basic usage examples for AutoFixture. It uses a specific verb ('Get') and resource ('quick start guide'), distinguishing it from sibling tools like 'get_best_practices' or 'fetch_github_docs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get common usage patterns and code examples
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | No | Pattern name or keyword (e.g., 'customizing', 'lists', 'automaq', 'xunit') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose safety and behavioral traits. It only describes the output (patterns and examples) but does not mention whether the tool is read-only, requires authentication, or has rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence. While concise, it could be slightly expanded to include context or usage hints without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description fails to specify the format, scope, or limitations of the returned code examples. More detail is needed for a tool that provides complex output like patterns and examples.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and the parameter 'pattern' includes a descriptive explanation with examples. The description adds no further value beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'common usage patterns and code examples', which matches the name. However, it does not differentiate from sibling tools like get_best_practices, which likely have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_best_practices or search_methods. The agent receives no clues about the appropriate context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for AutoFixture methods and their usage
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for method names (e.g., 'Create', 'Build', 'Freeze') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the tool searches for methods and usage, without disclosing behavioral traits like pagination, read-only nature, or expected response format. This is insufficient for an agent to understand side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient and front-loaded. It could be slightly more informative without becoming verbose, but it avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple input, the description still fails to explain what 'usage' means or what the agent should expect as output. It also does not disambiguate from 'get_usage_pattern'. More context is needed for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the sole parameter 'query', with a clear example. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching for AutoFixture methods and their usage. The name 'search_methods' aligns well. However, it does not differentiate from the sibling tool 'get_usage_pattern', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of alternatives like 'get_usage_pattern' or other siblings. The description lacks any conditional or contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0fetch_github_docsget_best_practicesget_class_infoget_packagesget_quick_startget_usage_patternsearch_methodsScored across 7 tools
Each tool targets a distinct aspect of AutoFixture documentation (e.g., fetching full docs, best practices, specific class info, packages, quick start, usage patterns, method search). Descriptions clearly differentiate them, leaving no ambiguity.
All tool names follow a consistent verb_noun pattern using underscores (fetch_github_docs, get_best_practices, etc.). The verbs 'fetch', 'get', and 'search' are all appropriate and uniform.
With 7 tools, the server is well-scoped for a documentation-focused AutoFixture helper. Each tool earns its place, covering the main information needs without overwhelming the user.
The tool set covers nearly all common documentation requests: full docs, best practices, classes, packages, quick start, patterns, and method search. A minor gap is the lack of version-specific changelogs or troubleshooting, but core coverage is solid.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol (MCP) server for Selise Blocks Cloud integration
An MCP server that automatically collects feedback on your MCP server.
MCP server for autoxingtech documentation, generated by doc2mcp.
