Supports documentation generation for C/C++ source code, parsing classes, functions, and variables to produce comprehensive documentation.
Provides full access to Doxygen's documentation generation capabilities, including project initialization, configuration management, and documentation generation in multiple formats like HTML, PDF, XML, and more.
Offers extended support for generating documentation from Fortran source code.
Supports documentation generation for JavaScript code, with extended capabilities for creating comprehensive documentation.
Generates documentation output in LaTeX format, which can be further processed into PDF documents.
Provides additional support for Perl documentation through extension mapping.
Provides primary support for PHP documentation generation, creating structured documentation from PHP source code comments.
Enables documentation generation for Python code with primary support, extracting documentation from code comments.
Generates UML diagrams as part of the documentation, including inheritance graphs and call graphs.
Creates documentation in XML format for further processing or integration with other systems.
Click on "Install 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., "@Doxygen MCP Server generate documentation for my Python project at /home/user/projects/api"
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 comprehensive Model Context Protocol (MCP) server that provides full access to Doxygen's documentation generation capabilities. This server enables AI assistants like Claude to generate, configure, and manage documentation for any supported programming language through a clean, powerful interface.
Refer to the docs/ directory in this repository for more comprehensive documentation.
The Doxygen MCP Server automates the generation of documentation from source code comments, parsing information about classes, functions, and variables to produce output in formats like HTML and PDF. By simplifying and standardizing the documentation process, it enhances collaboration and maintenance across diverse programming languages and project scales.
Related MCP server: MCP Documentation Server
Project Management: Initialize and configure Doxygen projects with intelligent defaults
Multi-Language Support: Full support for C/C++, Python, PHP, Java, C#, JavaScript, and more
Documentation Generation: Generate comprehensive documentation in multiple formats
Validation & Analysis: Check documentation coverage and identify missing documentation
Diagram Generation: Create UML diagrams, inheritance graphs, and call graphs
Configuration Management: Advanced Doxyfile creation and management
Primary Support:
C, C++, Python, PHP
Extended Support:
Java, C#, JavaScript, Objective-C, Fortran, VHDL, IDL
Additional Support (via extension mapping):
Batch, PowerShell, Bash, Perl, Go, and more
HTML (with interactive navigation)
LaTeX and PDF
XML (for further processing)
RTF (Rich Text Format)
Man pages
DocBook
Python 3.11+
Doxygen (required) - Installation guide
uv package manager - Installation guide
Graphviz (optional, for diagrams) - Installation guide
LaTeX (optional, for PDF) - Installation guide
Claude Desktop or Claude for Windows
# Ubuntu/Debian
sudo apt-get install doxygen
# macOS
brew install doxygen
# Windows
# Download from https://www.doxygen.nl/download.html# Clone repository
git clone <repository-url>
cd doxygen-mcp
# Install with uv
uv syncEdit your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add Doxygen MCP to mcpServers:
{
"mcpServers": {
"doxygen-mcp": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/doxygen-mcp",
"run",
"doxygen-mcp"
],
"env": {}
}
}
}Windows Example:
{
"mcpServers": {
"doxygen-mcp": {
"command": "C:\\Users\\YourName\\.local\\bin\\uv.exe",
"args": [
"--directory",
"D:\\dev\\doxygen-mcp",
"run",
"doxygen-mcp"
],
"env": {}
}
}
}Close and reopen Claude Desktop to load the new MCP server.
In Claude, try:
What MCP tools do you have available?You should see Doxygen MCP tools listed.
Create a Doxygen project for my C++ codebase at /path/to/projectClaude will initialize a Doxygen project with appropriate configuration.
For comprehensive documentation, see:
Installation & Usage: USING.md
Troubleshooting: BUGS.md
Contributing: CONTRIBUTING.md
See CONTRIBUTING.md for contribution guidelines.
This project is licensed under the GNU General Public License version 3 (GPLv3). See COPYING.md for the full license text.
For bug reports and troubleshooting, see BUGS.md.
Real-time documentation preview
Integration with popular IDEs
Custom theme support
Advanced search capabilities
Multi-repository documentation
CI/CD integration helpers
Performance analytics
Documentation quality scoring
v1.0.0: Initial release with full MCP support for all features of Doxygen up to and including version 1.14.0.
For more information about Doxygen itself, visit doxygen.nl.
Verify Doxygen installation and capabilities
| Name | Required | Description | Default |
|---|---|---|---|
| detailed | No | ||
| check_dot | No | ||
| check_latex | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior fully. It only says 'Verify' without explaining what is checked, how results are returned, or side effects. The boolean parameters suggest configurable checks, but this is not stated.
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 very short (5 words), which is concise but too brief for a tool with 3 parameters. It sacrifices necessary 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 the output schema exists, return values need not be explained. However, the tool's three boolean parameters have no descriptions, making the tool's usage unclear for agents.
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 description coverage is 0%, so the description must compensate. It mentions no parameters, leaving their purpose completely undocumented.
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 'Verify Doxygen installation and capabilities' clearly states the verb and resource, distinguishing it from creation tools. However, it does not explicitly differentiate from siblings like validate_documentation.
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 on when to use this tool versus alternatives. The description lacks any context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a Doxyfile configuration with specified settings
| Name | Required | Description | Default |
|---|---|---|---|
| template | No | standard | |
| output_path | Yes | ||
| project_settings | No | ||
| language_optimizations | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'generate', implying file creation via output_path, but does not mention side effects (overwrite), required permissions, or validation checks.
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 single-sentence description is concise with no redundant information. It could be more structured by front-loading key aspects like output and dependencies, but it remains efficient.
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 4 parameters, no annotations, and an output schema, the description is vastly incomplete. It omits parameter explanations, behavioral details, and return value context, making it insufficient for correct tool usage.
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 description coverage is 0%, yet the description adds no parameter details. Terms like 'template', 'project_settings', and 'language_optimizations' are not explained, forcing reliance on parameter names only.
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 'Generate a Doxyfile configuration with specified settings' clearly indicates the tool creates a Doxyfile. However, it does not differentiate from the sibling 'create_doxygen_project' which might create a full project, leaving some ambiguity.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives like 'create_doxygen_project' or prerequisites (e.g., Doxygen installation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initialize a new Doxygen documentation project with configuration
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | mixed | |
| project_name | Yes | ||
| project_path | Yes | ||
| extract_private | No | ||
| include_subdirs | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose side effects (e.g., directory creation, config generation), permissions, or idempotency. Fails to carry burden of behavioral disclosure.
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 is very concise, but lacks structure (no parameter explanations, no usage hints). Minimalism reduces helpfulness.
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?
Despite having an output schema, the description omits what the output represents, parameter details, and behavioral traits. Incomplete for a 5-parameter tool with no annotations.
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 description coverage is 0%, and description adds no parameter meanings. 'With configuration' is too vague to explain project_name, project_path, language, etc.
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?
Description clearly states it initializes a Doxygen project, distinguishing from siblings like generate_documentation. Verb 'Initialize' and resource 'Doxygen documentation project' are specific.
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 on when to use this tool vs. siblings like check_doxygen_install or create_doxyfile. Lacks prerequisites or usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate documentation from source code using Doxygen
| Name | Required | Description | Default |
|---|---|---|---|
| verbose | No | ||
| clean_output | No | ||
| project_path | Yes | ||
| output_format | No | html |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral details. It does not explain side effects (e.g., overwriting output), error handling, or the impact of parameters like clean_output. The description is too vague.
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 only one sentence, which is too brief for a tool with four parameters and an output schema. It lacks structure and does not provide essential details, sacrificing completeness for 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 complexity (multiple parameters, output schema, sibling tools), the description omits context: how it integrates with tools like create_doxyfile or validate_documentation, what output it produces, and any constraints. It is not comprehensive enough for an agent to use effectively.
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 schema has 0% description coverage and the tool's description adds no information about any parameter. The meaning of project_path, output_format, clean_output, and verbose is not clarified beyond the schema's basic types and defaults.
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: generating documentation from source code using Doxygen. This is specific and distinguishes it from sibling tools like check_doxygen_install or create_doxyfile.
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 (e.g., after creating a Doxyfile, or for final output). Prerequisites (like Doxygen installation) are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze project structure and identify documentation opportunities
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It states purpose but does not disclose whether the tool modifies files, requires specific permissions, or has side effects. The read-only nature is implied but not confirmed, and no details about performance or limits are given.
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 of 8 words is highly concise. However, the extreme brevity sacrifices necessary details, making it less effective than a slightly longer, more informative statement. It earns a 4 for efficiency but loses a point for insufficient content.
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 existence of an output schema and a single parameter, the description is too sparse. It fails to explain what 'documentation opportunities' means, how the output relates to sibling tools, or how the agent should use the results. The tool's role in a documentation pipeline is unclear.
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 description coverage is 0% and the description omits any explanation of the single parameter 'project_path'. No value is added beyond the schema's basic type and requirement, leaving the agent without guidance on path format, valid values, or scope.
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?
Description uses specific verb ('analyze') and resource ('project structure'), clearly stating its role to identify documentation opportunities, which distinguishes it from sibling tools that handle doxygen installation, configuration, generation, and validation.
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 guidance on when to use this tool versus siblings. It does not mention prerequisites, typical workflow position, or scenarios where other tools are preferred, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Suggest appropriate file patterns for a project
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| include_tests | No | ||
| include_examples | No | ||
| primary_language | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits beyond the basic purpose. It does not mention side effects, prerequisites, or what the tool returns (despite having an output schema).
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 extremely concise (one sentence) with no wasted text, but it is underspecified given the complexity of four parameters and an output schema. Conciseness is positive but sacrifices necessary 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?
The description is incomplete for a tool with multiple parameters and an output schema. It lacks context about the tool's role in the documentation workflow (e.g., suggesting patterns for Doxygen configuration), making it hard for an agent to select appropriately.
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?
With 0% schema description coverage, the description adds no meaning to the parameters. For example, 'project_path', 'primary_language', 'include_tests' are not explained; the description only says 'file patterns' without linking to parameters.
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 'Suggest appropriate file patterns for a project' states a clear verb and resource, but it is vague about what 'file patterns' means and lacks differentiation from sibling tools such as 'scan_project' or 'generate_documentation'.
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 like 'scan_project' or 'validate_documentation'. The description gives no usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check for documentation warnings, missing docs, and coverage analysis
| Name | Required | Description | Default |
|---|---|---|---|
| project_path | Yes | ||
| output_format | No | text | |
| check_coverage | No | ||
| warn_undocumented | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects or permissions. It only says 'check', implying read-only, but does not confirm whether the tool modifies anything, requires specific access, 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 sentence, which is concise but lacks necessary detail for an agent to use the tool correctly. It could be expanded without losing conciseness.
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?
Despite a simple purpose, the tool has four parameters and an output schema. The description does not mention return values (though output schema exists) or how coverage analysis is reported, leaving significant gaps for agent interpretation.
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 0% description coverage, and the description does not explain any parameters. For example, 'project_path' is required but missing context on format or scope; 'output_format' default 'text' is unexplained.
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 purpose: checking for documentation warnings, missing docs, and coverage analysis. It uses a specific verb 'check' and resource 'documentation', distinguishing it from sibling tools like 'generate_documentation' or 'scan_project'.
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 'generate_documentation' or 'scan_project'. There are no usage constraints, prerequisites, or scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: checking installation, creating config, initializing project, generating docs, scanning project, suggesting patterns, and validating. No ambiguity.
All tool names follow a consistent verb_noun pattern (e.g., check_doxygen_install, create_doxyfile, generate_documentation), using lowercase snake_case throughout.
With 7 tools, the server is well-scoped for its purpose of Doxygen documentation management. Each tool is necessary and balanced.
The tool set covers the full lifecycle from installation verification to documentation generation and validation, with additional analysis and suggestion tools. No obvious gaps.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
An MCP server that gives your AI access to the source code and docs of all public github repos
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/hoyt-harness/doxygen-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
