knowledge-base-mcp
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., "@knowledge-base-mcpwhat are the latest updates in artificial intelligence?"
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.
knowledge-base-mcp
An MCP server exposing a knowledge base to LLM clients through tools, resources, and prompts.
Layout
knowledge_base_mcp/
├── __init__.py
├── __main__.py # `python -m knowledge_base_mcp`
├── context.py # AppContext + app_lifespan (constructs the store)
├── server.py # FastMCP instance, CLI entry point (main)
├── tools.py # @mcp.tool() definitions (add_document, search)
├── resources.py # @mcp.resource() definitions (get_document)
├── prompts.py # @mcp.prompt() definitions
└── store/ # pluggable persistence layer
├── __init__.py # create_store() factory
├── base.py # KnowledgeBaseStore Protocol
└── sqlite.py # SQLite reference implementation
tests/
├── conftest.py # shared anyio_backend fixture
├── unit/ # SqliteKnowledgeBaseStore, in isolation
├── integration/ # tools/resources via an in-memory MCP session
└── e2e/ # real subprocess over stdio (not in the default run)See docs/specs/knowledge-base-store.md for the design and docs/adrs/ for why things are the way they are.
Related MCP server: Internal Documentation Search
Setup
uv syncRun
uv run knowledge-base-mcp # stdio transport (default)
uv run knowledge-base-mcp --transport streamable-http --port 8000Or inspect it interactively with the MCP Inspector:
uv run mcp dev knowledge_base_mcp/server.pyTest
uv run pytest # unit + integration, gated at 90% coverage
uv run pytest tests/e2e --no-cov # e2e: spawns the real server subprocess over stdiouv run pytest fails outright if coverage drops below 90% (--cov-fail-under=90 in pyproject.toml). tests/e2e is excluded from that default run (see testpaths) since it's slower and its coverage isn't collected in-process.
Lint / type-check
uv run ruff check .
uv run pyrightAvailable Tools
2 toolsadd_documentB
Add a new document to the knowledge base.
Args:
title: Title of the document.
content: Full text content of the document.
labels: Labels to tag the document with (optional).
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| labels | No | ||
| content | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| doc_id | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but does not disclose behavioral traits such as idempotency, duplication handling, or authorization requirements.
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 compact with one sentence and a parameter list. The 'Args:' block adds value but slightly repeats schema information; still concise overall.
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 simple tool with three parameters and an output schema, the description covers the basics but lacks usage guidelines and behavioral context, leaving gaps.
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?
Despite 0% schema description coverage, the description provides meaningful explanations for all three parameters (title, content, labels) that go beyond the schema names and types.
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 explicitly states 'Add a new document to the knowledge base,' using a specific verb and resource. It clearly differentiates from the sibling tool 'search'.
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, nor any prerequisites or exclusions. The description only states what the tool does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchA
Search the knowledge base by free-text terms and/or labels.
Args:
terms: Words/phrases to partial-match against title and content.
term_operator: "AND" requires every term to match, "OR" requires any one to match.
labels: Labels to filter on.
label_operator: "AND" requires every label, "OR" requires any one label.
limit: Maximum number of results to return.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| terms | No | ||
| labels | No | ||
| term_operator | No | AND | |
| label_operator | No | AND |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes partial matching behavior and operator logic. No annotations exist, so description carries full burden. Could add more about result ordering or error handling, but covers core behaviors.
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?
Concise docstring format with clear Args section. Every sentence adds value with no redundancy.
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 5 parameters (0 required), output schema exists, the description covers all parameter semantics and search logic. Output details are handled by output schema, so no further explanation needed.
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 fully explains each parameter: terms are partial-matched, operators control matching logic, labels filter, limit caps results. Adds significant meaning beyond bare schema.
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?
Clearly states 'Search the knowledge base by free-text terms and/or labels' using a specific verb and resource. Distinguishes from sibling tool 'add_document' by its search functionality.
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?
Provides detailed usage for each parameter including operators and limit. Implicitly distinguishes from add_document but lacks explicit when-to-use or when-not-to-use guidance.
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.
2 tool updates
v0.1.0- First observed
add_document - First observed
search
TDQS
add_document and search have completely distinct purposes: adding vs. finding documents. There is no overlap in functionality.
Both tool names are verbs, but add_document uses verb_noun while search uses a bare verb. The pattern is mostly consistent with a minor deviation.
Only 2 tools for a knowledge base server is too few. Typical operations like get, update, and delete are missing, making the surface feel incomplete.
The tools cover only 'add' and 'search', lacking retrieval by ID, update, and delete. This severely limits agent workflows for managing a knowledge base.
Maintenance
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
- KumbukaOAuthai.kumbuka
Governed, auditable knowledge your team curates for its AI assistants, self-hostable
Connect AI clients to biomedical data and tools.
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
11
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides tools for listing and retrieving content from different knowledge bases using semantic search capabilities.1853-
- FlicenseAqualityNot gradedmaintenanceExposes an internal engineering knowledge base to AI assistants, allowing users to search and retrieve standards, runbooks, and architecture decisions. It supports RAG-enhanced search, document scraping, and specialized prompts for incident investigation and code reviews.5-
- FlicenseAqualityCmaintenanceProvides MCP-compatible AI agents with read access to a LifeOS knowledge base, exposing identity, preferences, projects, wiki, skills, and rules via tools and resources.17-
- FlicenseNot gradedqualityDmaintenanceExposes tools for semantic search and RAG-based Q\&A from a local knowledge base, along with resources and prompt templates.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/gabor-trainer/knowledge-base-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server