Skip to main content
Glama
42Research

Dynamic MCP Server

by 42Research
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Dynamic MCP Server

A professional MCP (Model Context Protocol) server for crash dump analysis and kernel debugging.

Features

  • Real Crash Utility Integration: Execute actual crash utility commands with real output

  • Automatic Crash Dump Discovery: Find and list crash dumps in /var/crash

  • Intelligent Kernel Matching: Automatic kernel debug symbol detection and matching

  • Session Management: Robust crash analysis session lifecycle management

  • Multiple Dump Formats: Support for vmcore, core, crash, and dump files

  • Professional Forensics: Real kernel debugging and system forensics capabilities

Related MCP server: Crash MCP Server

Requirements

  • Crash Utility: Version 8.0.4+ (system package: crash)

  • Python: 3.10+ (3.11+ recommended)

  • Kernel Debug Symbols: Available in /usr/lib/debug/lib/modules/

  • Crash Dumps: Accessible in /var/crash/ or custom location

  • Permissions: Read access to crash dumps and kernel files

Installation

Quick Install (Recommended)

# Install directly from source
pip install -e .

Development Install

# Create virtual environment (optional but recommended)
python3 -m venv dynamic_mcp_env
source dynamic_mcp_env/bin/activate

# Install dependencies and package
pip install -e .

System Install

# Install system-wide (requires sudo)
sudo pip install .

System Install with Systemd Service

# Install system-wide with automatic systemd service setup
sudo pip install .

This automatically:

  • Installs the package

  • Copies the systemd service file

  • Creates the dynamic-mcp user and group

  • Creates required directories

  • Registers the service with systemd

See SYSTEMD_INSTALLATION.md for detailed systemd setup instructions.

Usage

Running the MCP Server

Stdio Mode (Default)

# Run the server with stdio transport
dynamic-mcp

# Or with module syntax
python -m dynamic_mcp.server

HTTP/SSE Mode

# Run the server with HTTP transport on default port 8080
dynamic-mcp-http

# Or with module syntax
python -m dynamic_mcp.server --http

# Access the server at: http://localhost:8080/sse

MCP Client Configuration

For Stdio Transport

Add to your MCP client configuration (e.g., Claude Desktop):

{
  "mcpServers": {
    "dynamic-mcp": {
      "command": "python",
      "args": ["-m", "dynamic_mcp.server"],
      "env": {
        "LOG_LEVEL": "INFO"
      }
    }
  }
}

For HTTP/SSE Transport

Configure your MCP client to connect to the HTTP endpoint:

{
  "mcpServers": {
    "dynamic-mcp": {
      "url": "http://localhost:8080/sse",
      "env": {
        "LOG_LEVEL": "INFO"
      }
    }
  }
}

Testing

# Run crash analysis tests
pytest tests/crash/

# Test crash utility integration
python tests/crash/test_crash_server.py

# Run all tests
pytest

Configuration

Create a .env file with optional configuration:

# Crash dump paths
CRASH_DUMP_PATH=/var/crash
KERNEL_PATH=/boot

# Session timeouts
CRASH_SESSION_TIMEOUT=180
CRASH_COMMAND_TIMEOUT=120

# Logging configuration
LOG_LEVEL=INFO
SUPPRESS_MCP_WARNINGS=true

MCP Tools

The server provides 5 comprehensive crash analysis tools:

1. crash_command

Execute crash utility commands with real output.

Parameters:

  • command (string): Crash utility command to execute

  • timeout (integer, optional): Command timeout in seconds (default: 120)

Example:

{
  "command": "sys",
  "timeout": 60
}

2. get_crash_info

Get information about current crash dump and session.

Returns:

  • Active session details

  • Available crash dumps

  • System requirements status

3. list_crash_dumps

List all available crash dumps.

Parameters:

  • max_dumps (integer, optional): Maximum number of dumps to return (default: 10)

Returns:

  • Crash dump details (name, path, size, timestamp)

  • Readability status

4. start_crash_session

Start a new crash analysis session.

Parameters:

  • dump_name (string, optional): Specific dump name (uses latest if not specified)

  • timeout (integer, optional): Session startup timeout (default: 180)

Returns:

  • Session startup status

  • Matched kernel information

5. close_crash_session

Close the active crash analysis session.

Returns:

  • Session closure status

Example Usage

Basic Crash Analysis Workflow

  1. List available crash dumps:

    # Use the list_crash_dumps tool

  2. Start a crash session:

    # Use start_crash_session tool (auto-selects latest dump)

  3. Execute crash commands:

    # System information
crash_command: "sys"

# Backtrace
crash_command: "bt"

# Process list
crash_command: "ps"

# Kernel log
crash_command: "log"

# Module information
crash_command: "mod"

  4. Close session when done:

    # Use close_crash_session tool

Troubleshooting

System Requirements

Crash utility not found:

# Install crash utility (RHEL/CentOS/Fedora)
sudo yum install crash
# or
sudo dnf install crash

# Install crash utility (Ubuntu/Debian)
sudo apt-get install crash

No crash dumps found:

  • Check /var/crash/ directory exists and has crash dumps

  • Ensure read permissions on crash dump files

  • Verify crash dumps are valid format (vmcore, core, etc.)

Kernel debug symbols missing:

  • Install kernel debug packages

  • Check /usr/lib/debug/lib/modules/ for debug symbols

  • Ensure kernel version matches crash dump

MCP Initialization Warnings

You may see warnings like:

WARNING - Failed to validate request: Received request before initialization was complete

This is normal MCP protocol behavior and doesn't affect functionality.

To suppress these warnings:

export SUPPRESS_MCP_WARNINGS=true

How It Works

  1. Crash Dump Discovery: Automatically scans /var/crash/ for crash dumps

  2. Kernel Matching: Finds matching kernel debug symbols in /usr/lib/debug/

  3. Session Management: Starts crash utility process with proper kernel and dump

  4. Command Execution: Uses pexpect to interact with crash utility process

  5. Output Capture: Returns real crash utility output with proper formatting

Supported Crash Analysis

Crash Commands

  • System Info: sys, mach, help

  • Process Analysis: ps, task, files

  • Memory Analysis: kmem, vm, search

  • Stack Analysis: bt, bt -a, bt -f

  • Kernel Analysis: log, dmesg, mod

  • Disassembly: dis, gdb

  • Lustre Analysis: Lustre-specific commands for filesystem debugging

Crash Dump Formats

  • vmcore: Standard Linux kernel crash dumps

  • core: Core dump files

  • crash: Crash utility format

  • dump: Generic dump files

Kernel Support

  • Debug Symbols: Automatic detection from /usr/lib/debug/

  • Kernel Versions: Support for multiple kernel versions

  • Lustre Kernels: Special support for Lustre filesystem kernels

Architecture

  • MCP Protocol: Full compliance with Model Context Protocol

  • Real Integration: Uses actual crash utility (not simulation)

  • Session Management: Robust process lifecycle management

  • Error Handling: Comprehensive error handling and recovery

  • Logging: Detailed logging for debugging and monitoring

License

This project is licensed under the MIT License.

Copyright © 2025 42Research Ltd

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software.

For full license terms, see the LICENSE file.

Contact: Email: software@42research.co.uk | Website: https://42research.co.uk

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Make your changes

  4. Add tests for new functionality

  5. Submit a pull request

Support

For issues and questions:

  • Check the troubleshooting section above

  • Review system requirements

  • Ensure crash utility and debug symbols are properly installed

Available Tools

7 tools
close_crash_sessionA

Close the current crash session

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior2/5

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

No annotations provided, so the description carries full burden. It implies a state-changing operation but does not disclose side effects, required permissions, or what happens to ongoing processes. The term 'current' is vague.

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?

Extremely concise at one sentence with no unnecessary words. Front-loaded action and resource.

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

Completeness3/5

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

For a simple tool with no parameters or output schema, the description is functional but lacks context on session management, such as how 'current' is defined or whether the session must be started first. Siblings suggest a lifecycle that is not explained.

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?

Zero parameters exist, so the description need not add parameter detail. The baseline is 4, and the description does not contradict or miss anything regarding parameters.

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 'Close the current crash session' uses a specific verb ('Close') and resource ('crash session'), clearly stating the action. It implicitly distinguishes from sibling tools like 'start_crash_session' by contrasting the operation.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as 'crash_command' or 'execute_bpftrace_script'. There is no mention of prerequisites (e.g., requiring an open session) or exclusions.

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

crash_commandB

Execute a command in the crash utility session

ParametersJSON Schema
NameRequiredDescriptionDefault
commandYesThe crash command to execute
timeoutNoCommand timeout in seconds (optional, default 120s for large dumps)

TDQS

B3/5.0
Behavior2/5

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

No annotations provided; description does not disclose behavioral traits like destructiveness, permission requirements, or return value. Minimal transparency despite carrying the full burden.

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

Conciseness3/5

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

Single sentence is concise but lacks additional context that could be included without verbosity. Under-specified for a command execution tool.

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

Completeness2/5

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

No output schema, but description does not explain return values or behavior. With two parameters and no annotations, more detail is needed for completeness.

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

Parameters3/5

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

Schema describes both parameters (command, timeout) with sufficient detail. Description adds no extra meaning over schema, so baseline 3 applies.

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?

Description clearly states the verb 'Execute' and resource 'command in the crash utility session', distinctly differentiating from sibling tools like start/close session or getting info.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., execute_bpftrace_script). Missing context such as needing an active session.

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

execute_bpftrace_scriptB

Execute a BPFtrace script for system tracing and analysis

ParametersJSON Schema
NameRequiredDescriptionDefault
scriptYesBPFtrace script content
timeoutNoScript execution timeout in seconds (optional, default 30s)
use_sudoNoWhether to use sudo for execution (optional, default true)

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided; description does not disclose behavioral traits such as side effects, required permissions, output format, or risks. The use_sudo parameter implies privilege escalation, but this is not addressed.

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

Conciseness4/5

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

Single sentence is concise and front-loaded with the key action and purpose. However, it sacrifices detail for brevity.

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

Completeness2/5

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

Without annotations and with no output schema, the description should provide more behavioral context (e.g., output format, safety warnings). For a potentially dangerous system tracing tool, this is insufficient.

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

Parameters3/5

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

Schema coverage is 100% with parameter descriptions, so baseline is 3. Description adds no extra meaning beyond parameter names and defaults.

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?

Description clearly states the action ('Execute'), resource ('BPFtrace script'), and purpose ('system tracing and analysis'). It distinguishes from sibling crash-related tools effectively.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives or any prerequisites. The description lacks context about appropriate scenarios or limitations.

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

get_bpftrace_infoA

Get information about BPFtrace availability and version

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

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

Without annotations, the description carries full burden. 'Get information' implies a read-only, idempotent operation. It explicitly names the type of info (availability and version), leaving little ambiguity. A score of 5 would require explicit mention of side-effect absence, but current text is sufficient.

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 a single clear sentence with no redundant words. It is front-loaded and efficiently conveys the tool's purpose.

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?

For a no-parameter, no-output-schema tool, the description adequately covers what the tool does (availability and version). It could optionally mention output format (e.g., boolean or string), but the lack is minor given the simplicity.

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?

There are no parameters, so the parameter coverage is 100%. The description does not need to add parameter details. Baseline for 0 parameters is 4, and no further explanation is required.

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 it retrieves information about BPFtrace availability and version, which is a specific verb+resource. It distinguishes itself from sibling tools like execute_bpftrace_script (which runs scripts) and crash-related tools, making its purpose unambiguous.

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

Usage Guidelines2/5

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. For example, it could mention using this before execute_bpftrace_script to verify bpftrace is installed, but it does not.

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

get_crash_infoB

Get information about the current crash dump and session

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

Without annotations, the description bears full responsibility. It only states a read action ('Get information') but does not disclose behavioral traits such as read-only nature, whether it requires a session, or any side effects. This lack of detail impedes safe invocation.

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

Conciseness4/5

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

The description is a single, concise sentence. It is appropriately sized for a simple parameterless tool, though slightly more context (e.g., what kind of information) would not detract from conciseness.

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

Completeness3/5

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

Given no output schema or annotations, the description is the sole source of context. It conveys the tool's purpose but omits what specific information is returned, leaving the agent to infer the exact payload. Adequate but not fully complete.

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 tool has zero parameters, so baseline is 4. The description does not need to add parameter details; it is sufficient that it names the resource being queried.

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 retrieves information about the current crash dump and session. It distinguishes from siblings like list_crash_dumps (listing all dumps) and get_bpftrace_info (BPF info), though it does not explicitly mention these alternatives.

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

Usage Guidelines2/5

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 vs. siblings or any prerequisites. For example, it does not indicate that an active crash session must be started first, leaving ambiguity about proper invocation order.

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

list_crash_dumpsA

List all available crash dumps

ParametersJSON Schema
NameRequiredDescriptionDefault
max_dumpsNoMaximum number of dumps to return (optional)

TDQS

A3.5/5.0
Behavior2/5

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

With no annotations, the description bears the burden of behavioral disclosure. It only states the tool lists dumps but does not mention return format, pagination, 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.

Conciseness5/5

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

The description is a single, short sentence with no extraneous information.

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

Completeness3/5

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

Given the tool has one parameter and no output schema, the description is adequate but lacks details on return format or default behavior.

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

Parameters3/5

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

Schema description coverage is 100% for the single parameter, so baseline is 3. The description adds no additional meaning beyond the schema.

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 'List all available crash dumps' clearly states the verb 'list' and the resource 'crash dumps', and it distinguishes itself from sibling tools which are all actions other than listing.

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?

No guidance is provided on when to use this tool versus alternatives like start_crash_session or get_crash_info. Usage is implied but not explicit.

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

start_crash_sessionC

Start a new crash session with a specific dump

ParametersJSON Schema
NameRequiredDescriptionDefault
dump_nameNoName of the crash dump file (optional, uses latest if not specified)
timeoutNoSession timeout in seconds (optional, default 120s for large dumps)

TDQS

C2.4/5.0
Behavior1/5

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

With no annotations, the description should disclose behavioral traits (e.g., session state, side effects, failure modes). It only states the action without any behavioral context.

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

Conciseness2/5

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

The description is a single sentence, but it is under-specified and lacks necessary details, making it ineffective rather than concise.

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

Completeness2/5

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

Despite full schema coverage, the tool is part of a session lifecycle. The description fails to provide context about session management, prerequisites, or return behavior.

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

Parameters3/5

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

Schema coverage is 100%, and the description adds no additional meaning beyond the schema. Baseline 3 is appropriate as the schema already describes parameters.

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 starts a new crash session with a specific dump, distinguishing it from siblings like close_crash_session or list_crash_dumps. However, it doesn't clarify that 'specific dump' is optional.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, such as needing to start a session before using crash_command or managing sessions. Context about session lifecycle is missing.

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

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

TDQS

B3.4/5.0
Disambiguation5/5

Each tool serves a distinct function: session lifecycle (start/close), execution (crash command, BPFtrace script), information retrieval (crash info, BPFtrace info), and listing dumps. No overlaps.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (e.g., close_crash_session, list_crash_dumps), but 'crash_command' breaks this pattern as a noun_verb, causing minor inconsistency.

Tool Count5/5

With 7 tools, the set is well-scoped for crash dump analysis and BPFtrace scripting. Each tool justifies its presence without being excessive or insufficient.

Completeness4/5

Core operations like session management, command execution, and info retrieval are covered. Minor gaps exist (e.g., no tool for saving sessions or filtering dumps), but not critical for the domain.

Maintenance

ActivitySlowing
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/42Research/dynamic_mcp'

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