How do I use Spec3 MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Spec3 MCP Server list all available tools" 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.

Spec3 MCP Server

by dhevenb

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Spec3 MCP Server

A Model Context Protocol (MCP) server built with FastMCP for local development and testing with Claude Desktop on WSL.

Overview

This MCP server provides a set of tools and utilities that can be used by Claude Desktop through the MCP protocol. It's designed to run locally on your WSL machine and connect to Claude Desktop via stdio.

Related MCP server: mytool3

Features

Modern Python Project Structure: Uses pyproject.toml and follows Python packaging best practices
FastMCP Integration: Built on the FastMCP framework for easy MCP protocol handling
Multiple Tools: Includes basic demonstration and utility tools
Comprehensive Logging: Detailed logging for debugging and monitoring
Type Hints: Full type annotation support for better development experience
WSL Compatible: Runs seamlessly on WSL and connects to Claude Desktop

Available Tools

hello_world: Returns a simple greeting message
echo_message: Echoes back a message with additional formatting
get_server_info: Returns comprehensive server information and capabilities
list_available_tools: Lists all available tools with descriptions

Installation

Prerequisites

Python 3.10 or higher
WSL (Windows Subsystem for Linux)
Claude Desktop (installed on Windows)

Setup

Navigate to the project directory:

cd /home/dhevb/workspaces/spec3-mcp-server

Create and activate a virtual environment:

python -m venv venv
source venv/bin/activate

Install the package in development mode:
```
pip install -e .
```
This will install the package and all its dependencies, including FastMCP.
Verify the installation:
```
spec3-mcp-server --help
```

Connecting to Claude Desktop

Configure Claude Desktop on Windows

Locate your Claude Desktop config file:
- On Windows, it's typically at: %APPDATA%\Claude\claude_desktop_config.json
- Full path is usually: C:\Users\YourUsername\AppData\Roaming\Claude\claude_desktop_config.json

Edit the configuration file and add the following:

{
  "mcpServers": {
    "spec3-mcp-server": {
      "command": "wsl",
      "args": [
        "-e",
        "/home/dhevb/workspaces/spec3-mcp-server/venv/bin/python",
        "/home/dhevb/workspaces/spec3-mcp-server/src/spec3_mcp_server/main.py"
      ],
      "env": {}
    }
  }
}

Note: The wsl command allows Claude Desktop on Windows to execute Python in your WSL environment.

Restart Claude Desktop to load the new configuration
Verify the connection:
- Open Claude Desktop
- Start a new conversation
- Look for the MCP tools icon or hammer icon
- You should see the spec3-mcp-server tools available

Alternative: Using Installed Command

If you prefer to use the installed spec3-mcp-server command:

{
  "mcpServers": {
    "spec3-mcp-server": {
      "command": "wsl",
      "args": [
        "-e",
        "/home/dhevb/workspaces/spec3-mcp-server/venv/bin/spec3-mcp-server"
      ]
    }
  }
}

Testing the Server

Test Locally (Without Claude Desktop)

You can test the server locally to ensure it's working:

# Activate your virtual environment
source venv/bin/activate

# Run the server directly
python src/spec3_mcp_server/main.py

The server will start and wait for MCP messages on stdin. You can verify it's running if you see the startup logs.

Test with Claude Desktop

Once connected to Claude Desktop, you can test the tools by asking Claude to use them:

"Use the hello_world tool"
"Echo this message: Hello from WSL!"
"Get server information"
"List all available tools"

Development

Project Structure

spec3-mcp-server/
├── src/
│   └── spec3_mcp_server/
│       ├── __init__.py          # Package initialization
│       ├── main.py              # Main entry point
│       ├── server.py            # MCP server implementation
│       └── http_server.py       # HTTP server (for network access)
├── tests/                       # Test files (to be added)
├── pyproject.toml              # Project configuration
├── README.md                   # This file
├── claude_desktop_config.json  # Example config for Claude Desktop
└── .gitignore                  # Git ignore rules

Adding New Tools

To add new tools to the MCP server:

Edit src/spec3_mcp_server/server.py
Add a new tool function decorated with @mcp.tool()
Add proper type hints and docstring

Example:

@mcp.tool()
async def my_new_tool(param: str) -> str:
    """
    Description of what this tool does.

    Args:
        param: Description of the parameter

    Returns:
        str: Description of the return value
    """
    logger.info(f"my_new_tool called with: {param}")
    return f"Processed: {param}"

Reinstall the package (if needed):
```
pip install -e .
```
Restart Claude Desktop to load the updated tools

Code Quality

The project includes configuration for:

Black: Code formatting
isort: Import sorting
mypy: Type checking
ruff: Linting
pytest: Testing

Run quality checks:

# Format code
black src/

# Sort imports
isort src/

# Type checking
mypy src/

# Linting
ruff check src/

# Run tests (when added)
pytest

Troubleshooting

Common Issues

Server won't start:
- Check that Python 3.10+ is installed in WSL: python --version
- Ensure FastMCP is installed: pip install fastmcp
- Verify virtual environment is activated: which python
Claude Desktop can't connect:
- Verify the paths in claude_desktop_config.json are correct
- Check that WSL is accessible from Windows
- Look at Claude Desktop's logs for connection errors
- Test the server manually in WSL first
Tools not appearing:
- Restart Claude Desktop after configuration changes
- Check server logs for errors
- Verify the server is running: ps aux | grep spec3-mcp-server
WSL-specific issues:
- Ensure WSL is properly installed: wsl --version
- Test WSL execution from Windows CMD: wsl -e python --version
- Check WSL distro is running: wsl -l -v

Logging

The server includes comprehensive logging. Check the console output for:

Server startup messages
Tool execution logs
Error messages and stack traces

To see logs when running via Claude Desktop, you can redirect them to a file by modifying the config:

{
  "mcpServers": {
    "spec3-mcp-server": {
      "command": "wsl",
      "args": [
        "-e",
        "/bin/bash",
        "-c",
        "/home/dhevb/workspaces/spec3-mcp-server/venv/bin/python /home/dhevb/workspaces/spec3-mcp-server/src/spec3_mcp_server/main.py 2>> /home/dhevb/workspaces/spec3-mcp-server/mcp-server.log"
      ]
    }
  }
}

Getting Help

If you encounter issues:

Check the server logs for error messages
Verify your Python and FastMCP versions
Test the server independently before connecting to Claude Desktop
Check the FastMCP documentation at https://github.com/jlowin/fastmcp
Review Claude Desktop's documentation for MCP configuration

Next Steps

Once you have the local server working:

Add more sophisticated tools for your specific use cases
Implement error handling for robust operation
Add tests to ensure reliability
Explore advanced MCP features like resources and prompts
Consider adding environment variables for configuration

License

MIT License - see LICENSE file for details.

Available Tools

3 tools

get_car_contextA

Get information about the user's 1994 BMW E36 325is Spec3 race car build.

Returns current configuration, build status, modifications, and car-specific details. Call this tool when providing personalized advice, troubleshooting, or planning modifications.

Returns: dict: Car configuration, history, and current state

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what the tool returns (configuration, build status, modifications, car-specific details) and implies it's a read-only operation by using 'Get information', but does not cover aspects like error conditions, authentication needs, or rate limits. This is adequate but has gaps for a tool with zero annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and concise, with three sentences that each serve a distinct purpose: stating the tool's purpose, providing usage guidelines, and describing the return value. There is no wasted text, and information is front-loaded effectively.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (0 parameters, no annotations, but an output schema exists), the description is mostly complete. It explains the purpose, usage, and return content. Since an output schema is present, the description does not need to detail return values, but it could benefit from more behavioral context (e.g., error handling).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately does not discuss parameters, earning a high baseline score. A 5 is reserved for cases where the description adds value beyond a perfect schema, which isn't applicable here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Get information') and the precise resource ('user's 1994 BMW E36 325is Spec3 race car build'), distinguishing it from sibling tools like get_document and list_documents which appear to handle generic documents rather than this specific car context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('when providing personalized advice, troubleshooting, or planning modifications'), offering clear context. However, it does not specify when NOT to use it or explicitly mention alternatives, which prevents a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_documentA

Retrieve full text and visual content of Spec3 racing reference documents.

Fetches complete PDF content from S3 including text and page images. Page images preserve diagrams, tables, and formatting that text extraction cannot capture.

Args: document_id: Document ID from list_documents (e.g., "spec3_rules") page_start: Starting page number (default: 1) page_end: Ending page number (default: None for all remaining pages) include_images: Include page images for diagrams/tables (default: True)

Returns: dict: Document text, page images (base64), metadata, and page range

ParametersJSON Schema

Name	Required	Description	Default
`document_id`	Yes
`page_start`	No
`page_end`	No
`include_images`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden and does so well by disclosing key behavioral traits: it fetches from S3, preserves diagrams/tables via page images that text extraction cannot capture, includes default values for parameters, and describes the return structure. It does not mention rate limits or auth needs, but covers essential operational details adequately.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, starting with the core purpose, followed by key details, and ending with return info. Every sentence adds value (e.g., explaining S3 source, image preservation, parameter semantics, and output structure) with zero waste, making it efficient and well-structured for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 parameters, 0% schema coverage, no annotations, but has output schema), the description is complete enough. It covers purpose, usage, parameters, and output details, compensating for the lack of schema descriptions and annotations. The output schema exists, so the description need not explain return values in depth, and it still provides a high-level overview of the return dict.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate fully. It adds significant meaning beyond the bare schema by explaining each parameter's purpose (e.g., 'document_id: Document ID from list_documents'), providing examples ('e.g., "spec3_rules"'), and clarifying defaults and effects ('include_images: Include page images for diagrams/tables'). This effectively documents all 4 parameters where the schema lacks descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Retrieve full text and visual content'), identifies the resource ('Spec3 racing reference documents'), and distinguishes it from siblings by specifying it fetches PDF content from S3, unlike 'get_car_context' or 'list_documents'. It explicitly mentions what the tool does beyond just listing or providing context.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool (to fetch complete PDF content with text and images) and implies usage by referencing 'document_id: Document ID from list_documents', suggesting it follows a list operation. However, it does not explicitly state when not to use it or name alternatives like 'list_documents' for just listing, leaving some guidance implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_documentsA

List all available Spec3 racing reference documents.

Available documents include: Spec3 Constructor's Guide, Bentley E36 Manual, 2025 NASA CCR rules, and 2025 Spec3 class rules.

Returns: dict: Document IDs, names, and descriptions

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses that the tool returns a dictionary with IDs, names, and descriptions, which is helpful behavioral context. However, it doesn't mention potential limitations like pagination, rate limits, or authentication needs, leaving gaps for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded: the first sentence states the purpose, followed by examples of available documents, and ends with return value details. Every sentence adds value without redundancy, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (0 parameters, no annotations, but with an output schema), the description is reasonably complete. It explains what the tool does, provides examples of documents, and describes the return format. However, it could be more complete by explicitly guiding usage relative to siblings or noting any constraints, slightly reducing the score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so the schema fully documents the lack of inputs. The description appropriately adds no parameter information, as none are needed, and instead focuses on output semantics. This meets the baseline of 4 for zero-parameter tools.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'List all available Spec3 racing reference documents' with a specific verb ('List') and resource ('Spec3 racing reference documents'). It distinguishes from sibling 'get_document' by indicating this lists available documents rather than retrieving a specific one, though it doesn't explicitly contrast with 'get_car_context'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by listing available documents and their types, suggesting this tool is for discovering what documents exist. However, it doesn't provide explicit guidance on when to use this versus 'get_document' (e.g., 'use this to find document IDs before retrieving content') or mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

3 tool updatesOct 6, 2025
- First observedget_car_context
- First observedget_document
- First observedlist_documents

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_car_context retrieves car-specific build information, list_documents lists available reference documents, and get_document fetches detailed content from those documents. The descriptions explicitly differentiate their scopes, making tool selection unambiguous.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern (get_car_context, get_document, list_documents) using snake_case throughout. The naming is predictable and readable, with verbs appropriately matched to actions (get for retrieval, list for enumeration).

Tool Count4/5

Three tools is a minimal but reasonable count for a specialized server focused on Spec3 racing information. It covers core needs (car context, document listing, and document retrieval), though it might feel slightly thin if expanded functionality (e.g., update or search tools) were expected for broader use cases.

Completeness4/5

The tool set provides complete coverage for retrieving Spec3 racing information: get_car_context handles car-specific data, while list_documents and get_document manage reference documents. A minor gap exists in lacking update or modification tools for the car context, but the retrieval-focused scope is well-defined and functional for its purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1
test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
11
mcp-aichatOAuth
io.github.AceDataCloud
MCP server for AI dialogue using various LLM models via AceDataCloud
AI & Machine Learning
2

Related MCP Servers

Claude-LMStudio-Bridge
AI & Machine Learning Developer Tools
infinitimeless
A
license
Not graded
quality
F
maintenance
A simple MCP server that enables Claude to communicate with locally running LLM models via LM Studio.
Updated a year ago (2025-03-21 17:22 UTC)
9
MIT
mytool3
Code Execution Developer Tools
reory
F
license
Not graded
quality
B
maintenance
A lightweight MCP server that bridges Claude AI with local Python execution, enabling personalized greetings and demonstrating local tool integration.
Updated 2 months ago (2026-07-22 13:57 UTC)
-
Simple MCP Server
File Systems Developer Tools
eshvargb
F
license
Not graded
quality
D
maintenance
A simple MCP server that provides basic utility tools for text manipulation, file operations, and calculations, intended to be connected to Claude AI desktop app.
Updated 10 months ago (2025-10-29 05:39 UTC)
-
my-first-mcp
Code Execution Developer Tools
imranshareefshaik
A
license
Not graded
quality
D
maintenance
A local MCP server that connects Claude Desktop to execute custom local code, such as generating custom greetings.
Updated 5 months ago (2026-03-31 14:22 UTC)
7
ISC

Appeared in Searches

Chinese greeting or conversation starter

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dhevenb/dheven-spec3-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server