Which integrations are available for this server?

Provides tools for managing GitHub wiki pages, including creating, reading, appending, listing, and deleting pages in a GitHub repository.

How do I use github-wiki-mcp?

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., "@github-wiki-mcp Create a wiki page called 'Home' with welcome content for myrepo." 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.

github-wiki-mcp

by andreahaku

Overview Schema Related Servers Score Discussions

JavaScript

Local

GitHub Wiki MCP Server

MCP (Model Context Protocol) server for managing GitHub wiki pages programmatically.

Features

This MCP server exposes the following tools:

write_wiki_page - Create or update a wiki page
read_wiki_page - Read the content of a wiki page
append_to_wiki_page - Append content to an existing page
list_wiki_pages - List all wiki pages in the repository
delete_wiki_page - Delete a wiki page

Related MCP server: wikijs-mcp-server

Installation

# Install dependencies
pnpm install

# Build the TypeScript project
pnpm build

Configuration

1. Create a GitHub Personal Access Token

Go to GitHub → Settings → Developer settings → Personal access tokens → Tokens (classic)
Click "Generate new token (classic)"
Select the repo scope (to access repository wikis)
Copy the generated token

2. Add the MCP server to Claude Desktop configuration

Edit the configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add this configuration:

{
  "mcpServers": {
    "github-wiki": {
      "command": "node",
      "args": [
        "/absolute/path/to/github_wiki_mcp/dist/index.js"
      ]
    }
  }
}

Replace /absolute/path/to/github_wiki_mcp with the actual path to the project directory.

3. Restart Claude Desktop

Close and reopen Claude Desktop to load the new MCP server.

Usage

Example: Write a wiki page about architecture

You can tell Claude:

Analyze the codebase using code-analysis-context-mcp to extract
all information about the repository architecture and write
a dedicated wiki page on GitHub called Architecture.

Claude will:

Use the code_analysis tool to get architecture information
Generate structured markdown content
Use write_wiki_page to create the page on GitHub

Direct Example: Create a wiki page

Create a wiki page called "API Documentation" on the repository
myusername/myrepo with this content:

# API Documentation

## Main Endpoints

- GET /api/users
- POST /api/users
- DELETE /api/users/:id

Example: Read an existing page

Read the content of the wiki page "Architecture" from the repository
myusername/myrepo

Example: Update an existing page

Add a "Deployment" section to the wiki page "Architecture"
with deployment instructions

Tool Reference

`write_wiki_page`

Creates or completely overwrites a wiki page.

Parameters:

owner (string, required): GitHub username or organization
repo (string, required): Repository name
token (string, required): GitHub personal access token
pageName (string, required): Page name (e.g., "Architecture")
content (string, required): Markdown content of the page
commitMessage (string, optional): Custom commit message

Output:

{
  "success": true,
  "page": "Architecture.md",
  "url": "https://github.com/owner/repo/wiki/Architecture"
}

`read_wiki_page`

Reads the content of an existing wiki page.

Parameters:

owner, repo, token: Same as above
pageName (string, required): Name of the page to read

Output:

{
  "success": true,
  "page": "Architecture.md",
  "content": "# Architecture\n\n..."
}

`append_to_wiki_page`

Appends content to the end of an existing page (or creates it if it doesn't exist).

Parameters:

owner, repo, token: Same as above
pageName (string, required): Page name
content (string, required): Content to append
commitMessage (string, optional): Commit message

`list_wiki_pages`

Lists all wiki pages in the repository.

Parameters:

owner, repo, token: Same as above

Output:

[
  {
    "name": "Architecture",
    "path": "Architecture.md",
    "size": 2048
  },
  {
    "name": "API-Documentation",
    "path": "API-Documentation.md",
    "size": 1024
  }
]

`delete_wiki_page`

Deletes a wiki page.

Parameters:

owner, repo, token: Same as above
pageName (string, required): Name of the page to delete
commitMessage (string, optional): Commit message

How It Works

The server uses the wiki Git repository (.wiki.git) instead of GitHub's REST API:

Clones the wiki repository to a temporary directory
Performs the requested operations (create/modify/delete .md files)
Commits and pushes the changes
Cleans up the temporary directory

This approach:

Is more reliable than REST APIs for wikis
Supports all standard Git operations
Has no content size limitations
Works with private repositories (if the token has permissions)

Integration with Other MCPs

With `code-analysis-context-mcp`

You can combine this server with your code-analysis-context-mcp to:

Automatically analyze the codebase
Extract documentation, architecture, APIs
Automatically write updated wiki pages

Example workflow:

Analyze the repository using code-analysis-context-mcp,
extract the complete architecture and create three wiki pages:
1. Architecture - overall project structure
2. API - endpoint documentation
3. Database - schema and relationships

Claude will use:

code_analysis.get_repository_architecture → analysis
github_wiki.write_wiki_page → Architecture page
github_wiki.write_wiki_page → API page
github_wiki.write_wiki_page → Database page

Security

Never share your GitHub token: The token has full access to repositories
Use tokens with minimum scope: Only repo is necessary
Consider using expiring tokens: For production environments
Don't commit the token: Ensure it's only provided at runtime

Development

# Watch mode during development
pnpm dev

# Production build
pnpm build

# Local installation for testing
pnpm link

Troubleshooting

Server doesn't connect

Verify that the path in claude_desktop_config.json is absolute and correct
Check that pnpm build has been executed
Verify Claude Desktop logs

Authentication error

Verify that the GitHub token is valid
Check that the token has the repo scope
Ensure the repository has wiki enabled (Settings → Wiki)

Wiki doesn't exist

GitHub automatically creates the wiki repository only when the first page is created manually. If the repository has never had a wiki:

Go to https://github.com/owner/repo/wiki
Click "Create the first page"
Create a test page
Now the MCP server will be able to access the wiki

License

MIT

Available Tools

5 tools

append_to_wiki_pageA

Append content to an existing wiki page. If the page does not exist, creates it with the provided content.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner (username or organization)
`token`	Yes	GitHub personal access token with repo scope
`content`	Yes	Markdown content to append
`pageName`	Yes	Name of the wiki page to append to
`commitMessage`	No	Optional commit message (defaults to "Append to {pageName}")

TDQS

A4/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 of behavioral disclosure. It reveals a non-obvious trait: the tool creates the page if it does not exist, which is more than the name alone suggests. However, it does not mention error conditions, permission checks (beyond token schema), or response structure, slightly limiting transparency.

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 extremely concise, using two short sentences that front-load the primary action and then add the fallback behavior. Every word earns its place, with no extraneous content.

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 simple append operation, the description covers the core behavior and the schema covers all parameters. No output schema is needed. The only gaps are minor edge cases (e.g., empty content, encoding) and explicit comparison with siblings, but overall it is sufficiently complete given the tool's simplicity.

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%, so the baseline is 3. The description reinforces that 'content' is appended and 'pageName' is the target, but it does not add parameter-specific details beyond the schema. This is acceptable since the schema already documents each parameter well.

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 a specific action ('Append content to an existing wiki page') with a defined resource ('wiki page'). The fallback behavior ('If the page does not exist, creates it') further distinguishes it from the sibling 'write_wiki_page', which implies overwriting rather than appending.

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 behavior implies usage – you use it when you want to add content without replacing existing content – but it does not explicitly compare against alternatives like 'write_wiki_page' or specify when to prefer one over the other. There are no exclusions or prerequisites beyond what the schema already notes.

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

delete_wiki_pageB

Delete a wiki page from a GitHub repository wiki.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner (username or organization)
`token`	Yes	GitHub personal access token with repo scope
`pageName`	Yes	Name of the wiki page to delete
`commitMessage`	No	Optional commit message (defaults to "Delete {pageName}")

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations available, the description carries the full burden of behavioral disclosure. It only says 'Delete' without noting irreversibility, permission requirements beyond the token scope, or potential side effects like cascading changes to wiki structure.

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, clear sentence that efficiently conveys the core purpose. It is front-loaded and wastes no words, though it may be slightly too terse given the lack of supplementary context.

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?

For a destructive operation with 5 parameters and no annotations or output schema, the description is insufficient. It omits important context such as the commit message default, the permanent nature of deletion, and error handling 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?

The schema covers all parameters with descriptions, so the baseline is 3. The tool description adds no additional semantic meaning beyond what the schema already provides.

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 action ('Delete') and the resource ('a wiki page from a GitHub repository wiki'), making it unambiguous and distinct from sibling tools like write, read, append, and list.

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, no mention of prerequisites or situations where deletion is appropriate. The description simply states what it does without context.

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

list_wiki_pagesA

List all wiki pages in a GitHub repository wiki.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner (username or organization)
`token`	Yes	GitHub personal access token with repo scope

TDQS

A3.8/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It states the operation (list all wiki pages) and hints at exhaustive results ('all'), but does not disclose return format, pagination behavior, or any edge cases. It is not contradictory, but offers only minimal 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.

Conciseness5/5

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

The description is a single, front-loaded sentence with no filler. Every word is informative, making it concise and well-structured.

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 simple read-only listing tool with no output schema, the description is largely sufficient: it clearly indicates the action and scope. However, it omits any mention of the response format (e.g., list of page titles or slugs), which would be needed for a fully self-contained description, but the simplicity of the tool keeps this from being a major gap.

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?

The input schema describes all three parameters (owner, repo, token) with 100% coverage, so the baseline is 3. The description adds no additional parameter-level meaning, only restating that it lists wiki pages in a repository.

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 verb 'List' and the resource 'all wiki pages in a GitHub repository wiki'. It distinguishes from sibling tools (write, read, append, delete) by explicitly focusing on listing all pages.

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 gives no explicit guidance on when to use this tool versus alternatives. The intended use is implied by the name and description, but no when-not-to-use or alternative tools are mentioned, so it remains at an implied level.

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

read_wiki_pageA

Read the content of an existing GitHub wiki page.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner (username or organization)
`token`	Yes	GitHub personal access token with repo scope
`pageName`	Yes	Name of the wiki page to read

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It clearly states the core behavior (reading content) and adds 'existing' to indicate it does not create pages. However, it does not disclose return format, error behavior for missing pages, or any permissions/rate-limit implications beyond the token in the schema. Basic transparency for a read operation, but lacking depth.

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 that directly states the tool's purpose without any redundant information. It is appropriately minimal and front-loaded.

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?

The tool has four required parameters and no output schema or annotations. The description explains what the tool does but does not describe the return value (e.g., content format, metadata), error conditions (e.g., page not found), or when to use it alongside siblings. Given the simplicity of the operation, this is sufficient for a basic read, but it lacks some 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 description coverage is 100%, so all four parameters (owner, repo, token, pageName) are already described at the schema level. The description adds no additional meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Read') and resource ('GitHub wiki page'), and adds 'existing' to clarify it does not create or modify. This clearly distinguishes it from siblings like write_wiki_page, append_to_wiki_page, delete_wiki_page, and list_wiki_pages.

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 phrase 'existing GitHub wiki page' implies the tool is for reading pages that already exist, but it does not explicitly say when to use it over alternatives, nor does it mention that list_wiki_pages could be used to discover page names. Usage context is implied by the tool name and sibling set, but no explicit guidance is provided.

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

write_wiki_pageA

Write or update a GitHub wiki page. Creates a new page or overwrites an existing one with the provided content.

ParametersJSON Schema

Name	Required	Description
`repo`	Yes	GitHub repository name
`owner`	Yes	GitHub repository owner (username or organization)
`token`	Yes	GitHub personal access token with repo scope
`content`	Yes	Markdown content for the wiki page
`pageName`	Yes	Name of the wiki page (e.g., "Architettura" or "API Documentation")
`commitMessage`	No	Optional commit message (defaults to "Update {pageName}")

TDQS

A3.8/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 of disclosing behavioral traits. It clearly states the destructive action of overwriting an existing page, which is the most important behavioral characteristic. It does not mention other aspects like auth requirements, rate limits, or return values, but the schema already covers the token parameter and no output schema exists.

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 two sentences long, front-loaded with the core purpose, and every sentence earns its place. It efficiently conveys the key functional scope and behavior without redundancy.

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 rich schema (100% parameter coverage) and the absence of an output schema, the description covers the essential behavior of creating or overwriting a wiki page. It could be more complete by explicitly directing users to append_to_wiki_page when they want to preserve existing content, but the overwrite language already implies this distinction.

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%, with all six parameters documented in the input schema. The description adds minimal parameter semantics beyond referencing 'provided content' for the content parameter, so it stays at the baseline for high schema coverage.

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 writes or updates a GitHub wiki page, with explicit coverage of creating new pages or overwriting existing ones. It uses a specific verb+resource (write/update wiki page) and partially distinguishes from siblings by noting the overwrite behavior, but it does not explicitly name alternative tools like append_to_wiki_page.

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?

Usage is implied through the overwrite behavior: the description says it 'overwrites an existing one,' suggesting it is not for appending. However, it does not explicitly state when to use this tool versus alternatives such as append_to_wiki_page, nor does it provide 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.

5 tool updatesv1.0.0Aug 10, 2026
- First observedappend_to_wiki_page
- First observeddelete_wiki_page
- First observedlist_wiki_pages
- First observedread_wiki_page
- First observedwrite_wiki_page

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct operation on wiki pages: write overwrites, read retrieves, append adds content, list enumerates, delete removes. There is no overlap or ambiguity among these operations, even though append can create a missing page, it is clearly distinct from write.

Naming Consistency5/5

All tools follow a verb_noun pattern (write_wiki_page, read_wiki_page, list_wiki_pages, delete_wiki_page), with append_to_wiki_page being the only minor deviation but still consistent in style. The pattern is predictable and clear.

Tool Count5/5

Five tools is an ideal size for a wiki page manager, providing all core operations without unnecessary bloat. Each tool earns its place in the set, and the scope is tightly focused.

Completeness5/5

The set covers the full CRUD lifecycle: create/write, read, update/append, list, and delete. All essential wiki page management operations are present, with no obvious gaps for the stated 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

ArletOAuth
dev.arlet
Create, deploy, and operate MCP servers directly from your GitHub repositories.
Developer Tools CI/CD & DevOps
2
neverinfamous-memory-journal-mcp
ai.smithery
A MCP server built for developers enabling Git based project management with project and personal…
Version Control Developer Tools Project Management
320
hiveWikiOAuth
ai.hivewiki
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Knowledge & Memory Note Taking Project Management
2
Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259

Related MCP Servers

GitHub MCP Serverofficial
Version Control Developer Tools File Systems
modelcontextprotocol
-
license
Not graded
quality
A
maintenance
MCP Server for the GitHub API, enabling file operations, repository management, search functionality, and more.
Updated 3 days ago (2026-09-03 01:42 UTC)
117,296
90,042
MIT
wikijs-mcp-server
Content Management Systems Documentation Access
markus-michalski
A
license
Not graded
quality
C
maintenance
MCP server for Wiki.js integration, enabling AI assistants to create, read, update, delete, search, and move wiki pages via natural language.
Updated 25 days ago (2026-08-12 07:22 UTC)
1
MIT
wikijs-mcp
Content Management Systems Documentation Access Knowledge & Memory
sondt2709
A
license
A
quality
C
maintenance
An MCP server for managing Wiki.js 2.x pages through its GraphQL API, enabling search, read, create, update, move, delete, version history, and asset listing.
Updated 2 months ago (2026-07-06 10:33 UTC)
13
33
MIT
GitHub MCP Server
Version Control Developer Tools
ampcome-mcps
A
license
Not graded
quality
D
maintenance
MCP server for the GitHub API, enabling file operations, repository management, search functionality, issues, pull requests, and more.
Updated a year ago (2025-07-07 10:34 UTC)
118
MIT

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/andreahaku/github_wiki_mcp'

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

GitHub Wiki MCP Server

Features

Installation

Configuration

1. Create a GitHub Personal Access Token

2. Add the MCP server to Claude Desktop configuration

3. Restart Claude Desktop

Usage

Example: Write a wiki page about architecture

Direct Example: Create a wiki page

Example: Read an existing page

Example: Update an existing page

Tool Reference

write_wiki_page

read_wiki_page

append_to_wiki_page

list_wiki_pages

delete_wiki_page

How It Works

Integration with Other MCPs

With code-analysis-context-mcp

Security

Development

Troubleshooting

Server doesn't connect

Authentication error

Wiki doesn't exist

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

GitHub MCP Serverofficial

Latest Blog Posts

MCP directory API

`write_wiki_page`

`read_wiki_page`

`append_to_wiki_page`

`list_wiki_pages`

`delete_wiki_page`

With `code-analysis-context-mcp`