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., "@Enterprise Knowledge Mesh search compliance documents for data retention policy"
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.
AI Runtime Platform Feature — tagged as
knowledge-mesh-mcp
Modern enterprises operate across multiple domains—legal, human resources, compliance, engineering, finance—each maintaining its own body of institutional knowledge. This knowledge is typically trapped in static documents, wikis, and PDFs, making it inaccessible to AI-powered assistants and automation pipelines. The Enterprise Knowledge Mesh solves this by exposing domain-specific knowledge bases as composable tools through the Model Context Protocol (MCP), enabling LLMs to retrieve relevant, filtered, and rank-ordered information from a unified data lake with zero boilerplate integration.
This project demonstrates how a renewable energy company with operations across multiple markets, device types, and regulatory regimes can centralize its fragmented knowledge into a single MCP server that any AI agent can query in real time.
Related MCP server: AXYS MCP Lite
Enterprise knowledge management suffers from three systemic failures:
Failure | Impact |
Siloed documentation | Legal contracts live in a DMS, HR policies in the intranet, compliance checklists in SharePoint. No single entry point. |
Context blindness | A query like "What are the warranty terms for solar panels in Berlin?" requires cross-referencing market-specific regulations, device-specific policies, and category-specific contract terms. |
No structured access for AI | LLMs cannot natively query internal databases. Prompt engineering with static RAG chunks is brittle, ungoverned, and unobservable. |
The result: employees waste hours searching for answers, compliance risks go undetected, and AI-assisted workflows stall because models cannot reliably access enterprise ground truth.
┌─────────────────────────────────────────────────────────┐
│ AI Agent / LLM │
│ (Claude, ChatGPT, Cursor, Copilot, custom agent) │
└────────────────────┬────────────────────────────────────┘
│ MCP Protocol (stdio/SSE)
▼
┌─────────────────────────────────────────────────────────┐
│ Enterprise Knowledge Mesh MCP Server │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Legal KB │ │ HR KB │ │ Compliance │ ... │
│ │ (MCP Tool) │ │ (MCP Tool) │ │ KB (MCP │ │
│ │ │ │ │ │ Tool) │ │
│ └──────┬───────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────┬────────┴────────┬───────┘ │
│ ▼ ▼ │
│ ┌──────────────────────────────────┐ │
│ │ TF-IDF Search Engine │ │
│ │ (tokenize → TF × IDF → rank) │ │
│ │ + filter pipeline │ │
│ └──────────────────────────────────┘ │
│ ▲ │
│ ┌────────┴────────┐ │
│ │ ServiceRegistry │ │
│ │ (YAML → class) │ │
│ └─────────────────┘ │
│ ▲ │
│ ┌────────┴────────┐ │
│ │ services.yaml │ │
│ │ (declarative │ │
│ │ config) │ │
│ └─────────────────┘ │
└──────────────────────────────────────────────────────────┘1. MCP Protocol as the Integration Standard
Rather than building a custom REST API or GraphQL endpoint, the server implements the Model Context Protocol—an open standard from Anthropic that defines how AI applications communicate with tools and data sources. This makes the knowledge mesh immediately compatible with every major AI assistant and IDE without adapter code.
2. Declarative Service Configuration
Services are defined in a single services.yaml file:
services:
- id: legal
name: Legal Knowledge Base
description: Contracts, policies, and regulatory information
markdown: src/services/legal/legal.md
- id: hr
name: HR Knowledge Base
description: Employee policies, benefits, leave, and workplace guidelines
markdown: src/services/hr/hr.md
- id: compliance
name: Compliance Knowledge Base
description: Regulatory compliance, data protection, audit requirements
markdown: src/services/compliance/compliance.mdAdding a new domain requires nothing more than a YAML entry and a markdown file. No routing code, no controller logic, no boilerplate.
3. Metadata-Driven Filtering
Each knowledge base and every section within it carries a metadata signature:
> **Markets:** Berlin, Frankfurt, Munich, Hamburg
> **Devices:** Solar Panel, Battery-Storage, Inverter
> **Categories:** Contracts, Warranty, LiabilityThis enables cross-dimensional filtering: queries can target a specific market, device, category, or any combination thereof. A compliance officer asking "What are the GDPR requirements for smart meters in Berlin?" gets results scoped to the intersection of market: berlin, device: inverter, category: gdpr.
4. TF-IDF Ranking for Relevance
The search engine uses a classic information-retrieval approach:
Tokenization splits queries and documents into normalized term vectors
Term Frequency (TF) measures how often a term appears within a section
Inverse Document Frequency (IDF) downweights terms that appear everywhere
Heading boost applies a multiplier (+2) when a query term matches a section heading
Top-3 truncation returns the three most relevant results per query
This approach is deterministic, auditable, and requires no external AI dependencies or GPU infrastructure.
Contracts, warranty terms, liability frameworks, consumer rights, data protection clauses, and grid connection requirements across four German markets (Berlin, Frankfurt, Munich, Hamburg). Covers devices: solar panels, battery storage, inverters, car chargers.
Remote work policies, vacation and leave regulations (including regional variations), parental leave top-ups, health insurance benefits, compensation and bonus structures, professional development budgets, onboarding processes, mental health programs, and anti-discrimination policies.
GDPR compliance for smart meter data, ISO 27001 information security requirements, VDE electrical safety standards, EEG 2023 renewable energy law, grid connection compliance, internal audit procedures, incident reporting obligations, and anti-corruption/ethics policies.
Node.js 20+
npm or yarn
An MCP-compatible client (Claude Desktop, VS Code with Cline, any custom agent)
git clone <repository-url>
cd acme-energy-mcp
npm install
npm run buildEdit services.yaml to add, remove, or modify knowledge bases. Each service requires:
id — unique identifier (used as the MCP tool name prefix)
name — human-readable label
description — tool description exposed to the LLM
markdown — path to the markdown file relative to project root
Each markdown file must include:
YAML frontmatter — service-level metadata bounded by --- delimiters:
---
name: Legal Knowledge Base
description: Contracts and regulatory information
markets: [berlin, frankfurt, munich, hamburg]
devices: [solar-panel, battery-storage, inverter, car-charger]
categories: [contracts, warranty, liability, consumer-rights, data-protection]
last_updated: 2025-11-15
---H2 sections — each ## Heading becomes a searchable chunk:
## Solar Panel Installation Contracts
> **Markets:** Berlin, Frankfurt, Munich, Hamburg
> **Devices:** Solar Panel
> **Categories:** Contracts, Consumer-Rights
All Acme Energy solar panel installation contracts include...npm run dev # Development (hot-reload via tsx)
npm start # Production (runs compiled dist/index.js)The server runs on stdio transport, which is the native integration mode for MCP clients.
To connect from any MCP-compatible client:
{
"mcpServers": {
"acme-energy-knowledge": {
"command": "node",
"args": ["/path/to/acme-energy-mcp/dist/index.js"]
}
}
}The server exposes one tool per knowledge base dynamically. For the three configured services, the LLM sees:
Tool Name | Description |
| Search the Legal Knowledge Base with optional market/device/category filters |
| Search the HR Knowledge Base with optional market/category filters |
| Search the Compliance Knowledge Base with optional market/device/category filters |
Each tool accepts a query string and optional market, device, and category filter parameters, populated dynamically from the frontmatter metadata.
npm test # Run all tests (vitest)
npm run test:watch # Watch mode
npm run typecheck # TypeScript type checking
npm run lint # ESLintCreate a markdown file in src/services/<domain>/<domain>.md with frontmatter and H2 sections
Add a YAML entry to services.yaml pointing to the new file
Restart the server — the new tool appears automatically
The TF-IDF implementation lives in src/search/engine.ts. It can be replaced with:
Embedding-based retrieval (OpenAI, Cohere, Voyage) for semantic search
BM25 for improved lexical matching
Hybrid search combining both with reciprocal rank fusion
Vector database integration (pgvector, Pinecone, Chroma) for scale
The IKnowledgeBase interface (src/types.ts) abstracts the search contract, so swapping engines requires no changes to the MCP server or service registry.
Phase | Feature | Status |
1 | Core MCP server with YAML-configurable knowledge bases | ✅ Complete |
2 | TF-IDF search with metadata filtering | ✅ Complete |
3 | Dynamic MCP tool generation from service config | ✅ Complete |
4 | Multi-market, multi-device, multi-category filtering | ✅ Complete |
5 | Embedding-based semantic search (pluggable engine) | 🔜 Planned |
6 | SSE transport for remote server deployment | 🔜 Planned |
7 | Authentication and authorization layer | 🔜 Planned |
8 | Analytics and usage observability | 🔜 Planned |
9 | Real-time content sync from upstream systems (SharePoint, Confluence) | 🔜 Planned |
10 | Cross-knowledge-base query routing ("ask anything") | 🔜 Planned |
Protocol, not framework. By implementing MCP, this project integrates with the entire AI ecosystem rather than a single vendor's platform.
Content over code. Knowledge is authored in plain markdown with YAML frontmatter—editable by domain experts, version-controlled in git, and deployable via CI/CD.
Deterministic retrieval first. TF-IDF is transparent, debuggable, and works offline. Semantic search can be layered on when needed, but the foundation is auditable.
Composable by default. Each knowledge base is an independent MCP tool. Agents can query one, many, or all, and the filter system enables precise cross-section queries.
Self-describing tools. The MCP tool definitions are generated from frontmatter metadata, so the LLM always knows which filters are available without hardcoding.
Component | Technology |
Runtime | Node.js 20+ (ESM) |
Language | TypeScript 5.8 (strict mode) |
MCP SDK |
|
Search | Custom TF-IDF engine |
Configuration | YAML via |
Validation | Zod 3.24 |
Testing | Vitest 3.1 |
Linting | ESLint 9 with typescript-eslint |
Private / Internal use. This project is designed as an enterprise internal tool.
This project was built as a coding challenge to demonstrate how the Model Context Protocol can serve as an enterprise knowledge mesh—transforming static documentation into composable, AI-accessible tools. The architecture patterns shown here are applicable across industries: financial services (regulatory handbooks), healthcare (clinical protocols), manufacturing (equipment manuals), and any organization where institutional knowledge must be made available to AI agents in a structured, filterable, and observable way.
List all available knowledge base services
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description accurately indicates a read-only list operation. No additional behavioral details are necessary for this simple tool.
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?
A single sentence that is concise and front-loaded, with no wasted words. It earns its place.
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?
For a parameterless tool with no output schema, the description fully suffices. It tells the agent exactly what to expect.
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?
There are zero parameters, so the schema already covers all. The description adds no extra parameter information, but the baseline of 4 is appropriate.
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 verb (list) and resource (knowledge base services), distinguishing it from sibling query tools. It is specific and unambiguous.
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?
The description implies usage for listing services before querying, but does not provide explicit when or when-not scenarios. Siblings are query tools, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Compliance Knowledge Base for relevant information. Use optional filters for more targeted results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string | |
| market | No | Filter by market. Examples: berlin, frankfurt, munich, hamburg, eu-wide | |
| device | No | Filter by device. Examples: solar-panel, battery-storage, inverter, car-charger | |
| category | No | Filter by category. Examples: gdpr, audit, iso-standards, environmental, electrical-safety, grid-compliance, reporting |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions searching but does not disclose whether it is read-only, how results are returned, pagination, or any side effects.
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?
Two short sentences convey purpose and guidance without any unnecessary words. Perfectly concise.
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 no output schema and moderate parameter count, the description lacks information about return structure or behavioral details, making it incomplete for confident use.
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 100%, so baseline is 3. The description adds minor context about optional filters but does not significantly expand on schema descriptions.
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 states 'Search the Compliance Knowledge Base for relevant information,' which includes a specific verb (search) and resource (Compliance Knowledge Base). It distinguishes from sibling tools like query_hr and query_legal which target different domains.
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?
The description says 'Use optional filters for more targeted results,' implying when to use optional parameters but does not explicitly state when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the HR Knowledge Base for relevant information. Use optional filters for more targeted results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string | |
| market | No | Filter by market. Examples: berlin, frankfurt, munich, hamburg, remote | |
| category | No | Filter by category. Examples: benefits, leave, remote-work, compensation, development, onboarding, policies, well-being |
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 only states 'Search', which implies a read-only operation, but provides no details on side effects, authorization needs, rate limits, or output characteristics (e.g., pagination, result limits). This is insufficient for a tool with no annotations.
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 concise with two sentences, no fluff. The first sentence states the core purpose, the second suggests filter usage. It is appropriately sized for a simple search tool, though it could be slightly more detailed 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?
Given the tool has 3 parameters, no output schema, and no annotations, the description covers the basic search functionality but lacks details on return format, result limits, or any behavior beyond the search itself. It is adequate but not complete.
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 coverage is 100%, so baseline is 3. The description adds that filters provide 'more targeted results', which provides context but does not add significant meaning beyond the schema's parameter descriptions and examples. The value is marginal.
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 searches the 'HR Knowledge Base', specifying the verb (Search) and resource (HR Knowledge Base). It mentions optional filters, which adds specificity. However, it does not explicitly differentiate from sibling tools like query_compliance or query_legal, which have similar structures but different domains.
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?
The description advises using optional filters for targeted results, implying usage context. However, it lacks explicit guidance on when to use this tool versus alternatives, and does not mention any prerequisites or when it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Legal Knowledge Base for relevant information. Use optional filters for more targeted results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query string | |
| market | No | Filter by market. Examples: berlin, frankfurt, munich, hamburg | |
| device | No | Filter by device. Examples: solar-panel, battery-storage, inverter, car-charger | |
| category | No | Filter by category. Examples: contracts, warranty, liability, consumer-rights, data-protection |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only indicates a search (read) operation but lacks details on side effects, rate limits, authentication, or data source characteristics.
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, clear sentence that front-loads the primary action. It is concise without waste, though more context could be added without harming 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?
Given no output schema and 4 parameters, the description adequately defines the tool's purpose but does not address return format, pagination, or result behavior. It is acceptable but has 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?
Input schema covers 100% of parameters with descriptions and examples. The description only says 'Use optional filters' which adds no new meaning beyond the schema. Baseline score of 3 is appropriate.
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 verb 'Search' and the resource 'Legal Knowledge Base', distinguishing it from sibling tools like query_compliance and query_hr by domain. It is specific and unambiguous.
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?
The description mentions using optional filters for targeted results, implying usage when legal information is needed. However, it does not explicitly state when to use tools like query_compliance or query_hr instead, nor does it provide 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0list_knowledge_servicesquery_compliancequery_hrquery_legalEach query tool targets a distinct knowledge base (compliance, HR, legal), and list_knowledge_services is clearly separate. No overlap in purpose.
All tools follow a consistent verb_noun pattern with snake_case: list_knowledge_services, query_compliance, query_hr, query_legal.
4 tools is well-scoped for a server focused on listing and querying knowledge bases. Not too many or too few.
The set covers listing and querying specific knowledge bases but lacks tools for adding, updating, or deleting content, and no cross-domain search.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Database for your AI agent. Turn its output into data, docs, skills, and apps you can actually use.
Structured knowledge base for AI agent solutions. Search, explore, and retrieve build logs.
Certified SEC EDGAR fact memory for AI agents with zero hallucination and filing provenance.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ashishsantikari/case-study-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
