Skip to main content
Glama
halans

Knowledge Base MCP Server

by halans
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

Knowledge Base MCP Server

A local MCP (Model Context Protocol) server that enables AI systems like Claude Desktop to search and query a knowledge base.

Features

  • Text Search: Search the knowledge base using natural language queries

  • Chunk Retrieval: Get specific chunks by ID for detailed information

  • Category Listing: Browse available topics in the knowledge base

Related MCP server: repocks

Installation

# Install dependencies
npm install

# Build the TypeScript code
npm run build

Available MCP Tools

Tool

Description

search_knowledge

Search for relevant information using a query string

get_chunk

Retrieve a specific chunk by its ID

list_categories

List all available categories in the knowledge base

Connecting to Claude Desktop

Add this server to your Claude Desktop configuration:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "knowledge-base": {
      "command": "node",
      "args": ["/path/to/local-mcp-simple/dist/index.js"]
    }
  }
}

After updating the config, restart Claude Desktop. You can then ask Claude to search the knowledge base, for example:

"Search the knowledge base for speed limits in school zones"

Development

# Build and run
npm run dev

# Or run separately
npm run build
npm start

Generating Knowledge Base

You can generate a new knowledge.json from any markdown file using the included script:

# Generate from a markdown file
npm run generate-knowledge -- ./path/to/your-document.md

# Specify output location
npm run generate-knowledge -- ./docs/handbook.md ./src/knowledge/knowledge.json

Markdown Format

The script parses markdown headings to create chunks:

  • H1 (#) - Sets the category for subsequent chunks

  • H2 (##) - Creates a new chunk with this title

  • H3 (###) - Also creates a new chunk with this title

  • H4 (####) - Included as bold text within the current chunk

Example markdown:

# Licences

## Getting your driver licence

To get a full driver licence, you need to go through three stages...

## Learner licence restrictions

There are licence restrictions that you need to follow...

# Speed Limits

## The rules

On roads where there's a speed limit sign, you must not drive faster...

This would create 3 chunks:

  1. "Getting your driver licence" (category: "Licences")

  2. "Learner licence restrictions" (category: "Licences")

  3. "The rules" (category: "Speed Limits")

Knowledge Base

The server uses src/knowledge/knowledge.json which contains pre-chunked content for search.

Available Tools

3 tools
get_chunkA

Retrieve a specific chunk from the knowledge base by its ID. Use this when you need the full content of a previously found chunk.

ParametersJSON Schema
NameRequiredDescriptionDefault
chunk_idYesThe ID of the chunk to retrieve (e.g., 'chunk-42')

TDQS

A3.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It implies this is a read operation ('Retrieve'), but doesn't address potential error conditions, authentication requirements, rate limits, or what happens if the chunk ID doesn't exist. The description adds basic context but lacks comprehensive behavioral details.

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 perfectly concise with two sentences that each serve distinct purposes: the first states the core functionality, the second provides usage guidance. There's zero wasted language or redundancy.

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 retrieval tool with one parameter and no output schema, the description is adequate but minimal. It covers the basic purpose and usage context but lacks details about return format, error handling, or behavioral characteristics that would be helpful given the absence of annotations.

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 fully documents the single parameter (chunk_id). The description adds minimal value beyond what the schema provides, only reinforcing that it retrieves by ID without adding format examples or constraints beyond the schema's description.

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

Purpose5/5

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

The description clearly states the specific action ('Retrieve a specific chunk') and resource ('from the knowledge base'), with explicit differentiation from sibling tools (list_categories, search_knowledge) by focusing on retrieval by ID rather than listing or searching.

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

Usage Guidelines4/5

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

The description provides clear context for when to use this tool ('when you need the full content of a previously found chunk'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools (list_categories, search_knowledge).

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

list_categoriesB

List all available categories in the knowledge base. Helpful for understanding what topics are covered.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a list operation but doesn't cover critical aspects like whether it returns a paginated response, if there are rate limits, authentication requirements, or what the output format looks like. This leaves significant gaps for an agent to use it effectively.

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 concise sentences with zero waste: the first states the core purpose, and the second adds a brief usage hint. It's front-loaded with the main action and efficiently structured without redundancy.

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 lack of annotations and output schema, the description is incomplete for a list operation. It doesn't explain what the return values are (e.g., list format, fields included), behavioral traits like pagination or sorting, or error conditions. This makes it inadequate for an agent to fully understand how to handle the tool's output.

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 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied for zero parameters, as it avoids unnecessary detail.

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 verb 'List' and resource 'all available categories in the knowledge base', making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from its siblings (get_chunk, search_knowledge) in terms of scope or function, which prevents a perfect score.

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 includes 'Helpful for understanding what topics are covered', which implies usage for topic exploration, but provides no explicit guidance on when to use this tool versus alternatives like search_knowledge or get_chunk. There are no prerequisites, exclusions, or named alternatives mentioned.

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

search_knowledgeC

Search the knowledge base for relevant information. Returns the most relevant chunks based on your query.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesThe search query (1-500 characters)
top_kNoNumber of results to return (default: 5, max: 20)

TDQS

C2.9/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 burden. It states the tool searches and returns relevant chunks, but lacks critical behavioral details: it doesn't mention if this is a read-only operation, how relevance is determined (e.g., semantic vs. keyword), whether results are paginated or limited, or any rate limits or authentication needs. The description is too vague for a tool with no annotation support.

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 concise with two sentences that directly state the tool's function and output. It's front-loaded with the main purpose. However, the second sentence could be more specific (e.g., 'Returns the top-k most relevant text chunks'), and there's some redundancy with 'relevant' repeated.

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 no annotations and no output schema, the description is incomplete. It doesn't explain what 'chunks' are (e.g., text snippets, documents), how results are formatted, or any error conditions. For a search tool with behavioral complexity, this leaves significant gaps for an AI agent to understand proper usage and expectations.

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 fully documents parameters 'query' and 'top_k.' The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain what constitutes a 'chunk' or how 'top_k' affects relevance). Baseline score of 3 is appropriate as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose: 'Search the knowledge base for relevant information' (verb+resource). It distinguishes from sibling 'get_chunk' (which likely retrieves a specific chunk) and 'list_categories' (which likely lists categories). However, it doesn't specify what 'knowledge base' refers to or the nature of 'chunks,' 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.

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 alternatives like 'get_chunk' or 'list_categories.' It mentions 'Returns the most relevant chunks' but doesn't clarify when searching is preferable over direct retrieval or listing. No exclusions, prerequisites, or context for usage are 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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedget_chunk
    • First observedlist_categories
    • First observedsearch_knowledge
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.3/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: get_chunk retrieves specific content by ID, list_categories enumerates available topics, and search_knowledge finds relevant information via query. There is no overlap or ambiguity between these functions.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (get_chunk, list_categories, search_knowledge) using snake_case throughout. The naming is predictable and readable.

Tool Count3/5

With only 3 tools, the set feels thin for a knowledge base server, lacking operations like create, update, or delete for managing content. However, it covers basic retrieval and exploration adequately.

Completeness2/5

The tool surface is significantly incomplete for a knowledge base domain, as it only supports read operations (get, list, search) without any write capabilities (e.g., add_chunk, update_chunk, delete_chunk). This will limit agents to querying only.

Maintenance

ActivityInactive
ResponsivenessNo issues

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

  • Library MCP

    lethain
    F
    license
    B
    quality
    D
    maintenance
    An MCP server that enables interaction with Markdown knowledge bases, allowing users to search and retrieve content by tags, text, URL, or date range from their local markdown files.
    7
    92
    -

  • repocks

    boke0
    A
    license
    Not graded
    quality
    D
    maintenance
    Transforms Markdown documentation into an intelligent knowledge base with AI-powered search and Q\&A through an MCP server.
    13
    9
    MIT

  • rag

    FrameMuse
    F
    license
    Not graded
    quality
    B
    maintenance
    A CLI tool and MCP server that turns markdown documentation into a searchable, queryable knowledge base.
    22
    -

  • context-server

    context-server
    A
    license
    Not graded
    quality
    A
    maintenance
    A lightweight MCP server for semantic search over markdown knowledge bases, enabling AI coding agents to index, search, and answer questions from local markdown documents.
    MIT

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/halans/local-mcp-simple'

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