How do I use wiki-helper?

1. Click on "Deploy 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., "@wiki-helper search wiki content for 'JWT' and summarize the top results" 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.

de en es ja ko pt ru zh

wiki-helper

by jarrelllong573-rgb

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

mcp-wiki-helper-tools

MCP server for querying a Wiki stored in a Git repository.

It syncs the Wiki, indexes the Markdown files, and provides tools to list, search, and read documents in Codex or VS Code.

Features

Tool	What it does
`Server`	Checks whether the MCP is working.
`list_documents`	Lists the Wiki documents.
`search_documents`	Searches by document name or path.
`search_content`	Searches within document content.
`read_document`	Reads a full Markdown document.

Related MCP server: knowledge-mcp

How it works

The MCP clones or updates the Wiki's Git repository.
Finds all .md files.
Creates an in-memory index.
Makes the tools available through the HTTP /mcp route.
Updates the Wiki periodically.

The folder defined in WIKI_LOCAL_PATH is updated with git reset --hard. Do not make manual changes to it, as they will be discarded.

1. Set up the server

On the machine where the MCP will run, enter the project folder:

cd "/caminho/para/mcp-wiki-helper"

Install the dependencies:

npm install

Create the .env file:

cp .env.example .env

Fill in the .env:

WIKI_REPOSITORY_URL=git@github.com:empresa/wiki.git
WIKI_LOCAL_PATH=./data/wiki
WIKI_BRANCH=main
WIKI_SYNC_INTERVAL_MS=1800000

MCP_HTTP_HOST=0.0.0.0
MCP_HTTP_PORT=3000
MCP_HTTP_ROUTE=/mcp

To make the first test easier on the local network, do not configure MCP_API_KEY.

2. Start the server

Compile:

npm run build

Start:

npm run start:http

Keep that terminal open. The expected message is:

[MCP] HTTP ativo em http://0.0.0.0:3000/mcp

Find out the machine's IP:

hostname -I

If necessary, open the port on the local network:

sudo ufw allow from 192.168.0.0/16 to any port 3000 proto tcp

3. Test the connection

On the other machine, run:

curl http://IP_DO_SERVIDOR:3000/health

Example:

curl http://192.168.3.233:3000/health

Expected response:

{
  "status": "ok",
  "documents": 100
}

The documents field must be greater than zero.

4. Connect in Codex

In Codex:

Open Settings.
Go to MCP servers.
Click + Add server.
Choose the URL/HTTP type.
Use the name wiki-helper.
Fill in only the URL:

http://IP_DO_SERVIDOR:3000/mcp

Example:

http://192.168.3.233:3000/mcp

Leave these fields completely empty:

Bearer token env var
Headers
Headers from environment variables

Do not write none in the authentication fields.

Then:

Save the server.
Turn on the toggle next to wiki-helper.
Open a new conversation in Codex.
Send:

Use list_documents do MCP wiki-helper e mostre os primeiros 10 documentos.

If Codex reports that the none environment variable does not exist:

Open Settings > MCP servers > wiki-helper.
Click Uninstall.
Add it again filling in only the URL.
Leave all authentication fields empty.

5. Connect in VS Code/Copilot

In VS Code:

Press Ctrl+Shift+P.
Run MCP: Open User Configuration.
Put it in the mcp.json file:

{
  "servers": {
    "wiki-helper": {
      "type": "http",
      "url": "http://IP_DO_SERVIDOR:3000/mcp"
    }
  }
}

Then run MCP: List Servers, select wiki-helper, and choose Start Server.

6. Usage examples

Check the server:

Use a ferramenta Server do MCP wiki-helper.

List documents:

Use list_documents do wiki-helper e mostre os primeiros 10 documentos.

Search by name:

Use search_documents do wiki-helper para procurar "autenticação".

Search within the Wiki:

Use search_content do wiki-helper para pesquisar "JWT", com limite 5.

Read a document:

Use read_document do wiki-helper para ler "caminho/documento.md" e faça um resumo.

Common issues

`ECONNREFUSED ...:80` error

The URL is missing the port or the route. Always use:

http://IP_DO_SERVIDOR:3000/mcp

The `/authorize` route opened

The client tried to use OAuth. This MCP does not have OAuth. Remove the authentication and leave the Bearer and Headers fields empty.

The MCP does not connect

Check on the server machine:

npm run start:http
ss -lntp | grep 3000

Test again on the client machine:

curl http://IP_DO_SERVIDOR:3000/health

The Wiki does not return documents

Check whether the configured folder contains Markdown files:

find ./data/wiki -type f -name '*.md' | head

Also check access to the Git repository configured in WIKI_REPOSITORY_URL.

Security

Use this unauthenticated mode only on a controlled local network.
Do not expose port 3000 directly to the internet.
For external access, use HTTPS, authentication, and a reverse proxy.
Never commit keys or credentials in .env.

Available Tools

5 tools

list_documentsList DocumentsB

Lista todos os documentos disponíveis na Wiki.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.1/5.0

Behavior2/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 of behavioral disclosure. It only states that the tool lists documents, but it does not describe what the returned list contains (e.g., IDs, titles, pagination, ordering, or whether it returns the full set or a sample). For a tool with no annotations and no output schema, this is insufficient for an agent to predict the tool's behavior.

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 sentence in Portuguese that is direct and front-loaded with the core action and object. There is no extraneous information, and it is appropriately concise for a tool with no parameters.

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?

The tool has no output schema and no annotations, so the description must compensate. It only says 'lists all documents' but does not specify what fields are returned, whether the result is paginated, or any other details an agent might need to consume the output. For a potentially large list, this is a notable gap.

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, and the schema coverage is trivially 100%. Per the calibration rules, when there are no parameters the baseline score is 4. The description does not need to explain parameters that don't exist, and it correctly avoids inventing any.

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 action ('Lista' = list) and the resource ('todos os documentos disponíveis na Wiki' = all documents available in the Wiki). It is distinct from the sibling tools by name and verb (list vs. search/read), but it does not explicitly call out the differentiation, so it loses a point for not addressing the sibling context.

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 versus the search or read tools. There is no mention of use cases, limitations, or alternatives. An agent would have to infer that list_documents is for enumerating all documents, but it has no explicit instruction on when that is appropriate.

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

read_documentRead DocumentB

Lê o conteúdo de um documento da Wiki pelo caminho.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Caminho do documento, por exemplo: "software/JWT.md"

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states that reading returns content, but does not mention error behavior for nonexistent paths, response format, or any side effects (though likely safe). This is a significant gap for a tool with zero annotation 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, concise sentence with no filler. The core action and resource are front-loaded, making it easy to parse quickly.

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 read tool with one parameter and no output schema, the description is adequate but not thorough. It explains the purpose and parameter, but lacks information about return value format or error handling, which would be useful without an output schema to clarify.

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 the 'path' parameter described and an example provided. The tool description adds no extra meaning about parameters beyond what the schema already covers, so the baseline score of 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?

The description clearly states the action (read), the resource (document content of the Wiki), and the method (by path). This distinguishes it from siblings like list_documents (listing) and search_documents/search_content (searching), so an agent can differentiate without extra 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 is given on when to use this tool versus alternatives. There is no mention of conditions like 'use this when you have a known path' or exclusions against using search tools. The context is minimal and relies on inference.

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

search_contentSearch Wiki ContentC

Pesquisa termos dentro do conteúdo dos documentos Markdown da Wiki.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Quantidade máxima de documentos retornados.
`query`	Yes	Termos que devem ser pesquisados na Wiki.

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the search action and target content, but omits details like case sensitivity, matching behavior, result ordering, or what happens with no matches. This is minimal and does not go beyond the schema.

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?

The description is a single concise sentence, but it is in Portuguese and adds no value beyond the schema. It is not overloaded, yet it also lacks useful context or differentiation, so it is acceptable but minimal.

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 tool with two parameters and no output schema, the description does not explain return format, errors, or how it differs from the very similar sibling 'search_documents'. This incompleteness could lead to incorrect usage or choice of the wrong tool, so more detail is needed.

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 schema already documents both 'query' and 'limit' thoroughly. The description does not add any extra meaning about parameters; it only restates that it searches terms, which matches the schema's existing text. Baseline of 3 is appropriate.

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 searches terms within wiki Markdown content, using a specific verb and resource. However, it does not differentiate from the sibling tool 'search_documents', which appears to have a nearly identical purpose, leaving ambiguity about which search tool to pick.

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?

There is no guidance on when to use this tool rather than alternatives like 'search_documents', 'list_documents', or 'read_document'. The description only says what it does, not when to use it, so an agent gets no context for selection.

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

search_documentsSearch DocumentsC

Busca documentos da Wiki pelo nome ou caminho.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Texto para pesquisar.

TDQS

C2.9/5.0

Behavior2/5

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

There are no annotations to back up the description, so the description carries the full burden of disclosing behavioral traits. It merely states what is searched (name/path) but does not disclose the nature of the search (exact match, fuzzy), whether results are paginated, what is returned (list of documents? paths?), or any side effects. Since it's a search, it's likely read-only, but that isn't stated. This is a significant gap.

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 front-loads the main action and scope. No unnecessary words. It is concise and readable. It would earn a 5 if it included a bit more useful context, but for its brevity it is well-structured.

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 simple search tool with one parameter and no output schema, the description should explain what the result looks like (e.g., a list of matches) or mention any limitations. It lacks this. Additionally, because there is a sibling 'search_content', the description should clarify the difference, but it doesn't. The description is too minimal to fully equip an agent to call the tool correctly.

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 100% of the parameter (query) with a description ('Texto para pesquisar.'). The tool description adds no additional meaning about the parameter's semantics, such as case sensitivity, wildcards, or format. With full schema coverage, the baseline is 3, and the description does not exceed it.

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 states a specific verb ('busca' – search), a resource ('documentos da Wiki' – Wiki documents), and a scope ('pelo nome ou caminho' – by name or path). This gives a clear purpose and implicitly differentiates from the sibling 'search_content' (which likely searches content). However, it does not explicitly name the sibling or articulate the differentiation, so it stops short of a 5.

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 versus the alternatives (list_documents, read_document, search_content). It does not mention exclusions, prerequisites, or contexts where another tool would be more appropriate. Without this, an agent may struggle to choose the correct tool.

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

ServerServer checkA

Verifica se o servidor MCP está funcionando.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/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 of behavioral disclosure. It only says 'verifies if the server is working' without specifying what the response looks like (e.g., a status field, a boolean, an error-free execution), or whether there are any side effects. This is a significant gap for a tool that an agent must interpret.

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, tightly worded sentence. It is front-loaded with the core action and resource, with no filler. For a tool with no parameters, this is appropriately sized.

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?

Given the tool has no output schema and no annotations, the description must explain what an agent can expect from a call. It only states the check occurs but does not describe the return value, possible error conditions, or how to interpret the result. This is incomplete for a tool that an agent would call and need to act on.

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?

With zero parameters, the schema has 100% coverage (no params to describe). Per the rubric, a 0-parameter tool gets a baseline of 4, and the description does not need to add parameter-specific meaning.

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 states a clear verb ('Verifica' / checks) and a specific resource (the MCP server), making the tool's purpose unambiguous. It is also clearly distinct from the sibling tools (which are all document-related), so an agent can tell it apart without extra 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 it is for checking server health, but gives no explicit guidance on when to use it versus alternatives. Since the siblings are unrelated, there is no confusion, but no explicit when/when-not or alternative naming is provided.

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.

5 tool updatesv1.0.0Aug 24, 2026
- First observedlist_documents
- First observedread_document
- First observedsearch_content
- First observedsearch_documents
- First observedServer

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored 2026-08-24 01:35 across 5 tools

Disambiguation5/5

Each tool has a clear, distinct purpose: health check, list all documents, read by path, search by name/path, and search content. No overlap or ambiguity exists among the tool operations.

Naming Consistency4/5

Most tools follow a consistent verb_noun pattern (list_documents, read_document, search_documents, search_content). The lone exception is 'Server,' which is a single-word health check and slightly breaks the pattern, but it remains readable and predictable.

Tool Count5/5

At 5 tools, the server is well-scoped for a wiki helper. Each tool covers a fundamental operation without redundancy or bloat, and the count is within the ideal 3-15 range.

Completeness4/5

The surface provides list, read, and two search capabilities, covering the primary read-only workflows for a wiki. It lacks create/update/delete operations, but these may be intentionally out of scope for a helper; minor gaps exist but are easily worked around by external tools.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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
agent-wikiOAuth
com.getagentwiki
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Documentation Access Note Taking Workplace & Productivity
1
OrchestKit Docs MCP A
io.github.yonatangross
Read-only MCP server for the OrchestKit docs: full-text search + Markdown fetch. No auth.
Documentation Access Search
23186
FlowdexOAuth
dk.flowdex
Read and write your team's shared, AI-readable wiki from any MCP client.
Note Taking Documentation Access Workplace & Productivity
1

Related MCP Servers

WikiStrata
Documentation Access Search Knowledge & Memory
kogarashi86
A
license
B
quality
D
maintenance
Enables querying and interacting with a Markdown wiki generated from Confluence pages, with search and MCP server for LLM access.
Updated 5 months ago (2026-04-20 04:05 UTC)
10
4
MIT
knowledge-mcp
Knowledge & Memory Documentation Access Search
c0cl3c
F
license
Not graded
quality
C
maintenance
Serves markdown knowledge from a git repository over MCP, providing tools to list, search, and retrieve documents.
Updated 3 months ago (2026-06-23 00:24 UTC)
-
py-mcp-wiki-helper
resoxcgp1em0dckdeppyxywiy-debug
A
license
Not graded
quality
C
maintenance
MCP server to query a Git-hosted Wiki, offering tools to list, search, and read Markdown documents via Codex or VS Code.
Updated 2 months ago (2026-07-26 17:04 UTC)
MIT
ai-wiki-mcp
Note Taking File Systems
jhonnold
F
license
Not graded
quality
B
maintenance
Provides structured search, schema-validated writes, and linting for a markdown knowledge base, enabling agents to operate the wiki over a single streamable-HTTP MCP endpoint.
Updated a month ago (2026-08-07 01:36 UTC)
1
-

mcp-wiki-helper-tools

Features

How it works

1. Set up the server

2. Start the server

3. Test the connection

4. Connect in Codex

5. Connect in VS Code/Copilot

6. Usage examples

Common issues

ECONNREFUSED ...:80 error

The /authorize route opened

The MCP does not connect

The Wiki does not return documents

Security

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`ECONNREFUSED ...:80` error

The `/authorize` route opened