Skip to main content
Glama
subzone

Knowledge Master

by subzone
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

⚡ Knowledge Master

Your codebase's memory. A local knowledge graph that gives AI agents real understanding of your architecture — not just text search.

License: MIT Status: Stable Python 3.11+

Why

Every time you start a new AI chat, it forgets everything. You re-explain your architecture, conventions, dependencies. Knowledge Master gives your AI permanent, structured memory about your entire system.

Unlike flat RAG tools that return "chunks about X", Knowledge Master builds a graph — so it can answer "what breaks if I change X?" by traversing actual relationships.

Related MCP server: codemap

What it does

  • 🔍 Semantic search across all your code, docs, and configs

  • 🕸️ Knowledge graph — relationships between services, people, repos, technologies

  • 💥 Blast radius — "what depends on this service/file/technology?"

  • 📏 Convention enforcement — detects and enforces your team's patterns

  • 🤖 MCP server — plugs directly into AI agents (Kiro, Claude, Cursor)

  • 🖥️ Web UI — search, browse, visualize your knowledge graph

  • 🔒 Local-first — nothing leaves your machine

Prerequisites

Dependency

macOS

Ubuntu/Debian

Windows

Docker

brew install colima && colima start or Docker Desktop

sudo apt install docker.io docker-compose-plugin

Docker Desktop

Ollama

brew install ollama && ollama serve

curl -fsSL https://ollama.com/install.sh | sh

Ollama installer

Python 3.11+

brew install python@3.12

sudo apt install python3.12 python3.12-venv

python.org

Quick Start

# Install (pick one)
pipx install knowledge-master         # recommended (isolated, clean)
pip install knowledge-master           # or with pip

# Or via Homebrew (macOS)
brew install pipx && pipx install knowledge-master

# Or from source
git clone https://github.com/subzone/knowledge-master.git
cd knowledge-master
python3 -m venv .venv && source .venv/bin/activate
pip install -e .

# One command setup
km start

# Index your first repo
km index ~/path/to/your/project

# Search
km search "authentication flow"

# Check blast radius
km blast-radius postgres

# Start web UI with graph visualization
km serve

Requirements: Docker, Ollama, Python 3.11+

Features

Semantic Search with Graph Context

$ km search "how does auth work"
┌────────┬──────────────────────┬─────────────────────┬──────────────────────┐
│ Score  │ Source               │ Context             │ Preview              │
├────────┼──────────────────────┼─────────────────────┼──────────────────────┤
│ 0.847  │ src/auth/service.py  │ repo:myapp, by:Alex │ JWT token validat... │
│ 0.791  │ docs/auth.md         │ repo:myapp          │ Authentication f...  │
└────────┴──────────────────────┴─────────────────────┴──────────────────────┘

Blast Radius Analysis

$ km blast-radius auth-service
💥 Blast radius: auth-service
├── ⚙️ user-service (Service, via DEPENDS_ON)
├── ⚙️ payment-service (Service, via DEPENDS_ON)
├── 📦 frontend (Repo, via USES_SERVICE)
└── 👤 Alex (Person, via AUTHORED)

4 entities affected

Convention Enforcement

$ km check-conventions ~/my-project
  ✓ src/ directory (structure)
  ✓ separate test directory (testing)
  ✗ snake_case files (file-naming)
  ✓ Repository pattern (design-pattern)

1 convention(s) violated

Web UI & Graph Visualization

$ km serve
Knowledge Master UI → http://127.0.0.1:9999

Interactive force-directed graph showing your entire knowledge topology:

  • 📦 Repos (blue) → 🔧 Technologies (red)

  • ⚙️ Services (orange) → Dependencies

  • 👤 People → Authorship

  • 📏 Conventions (purple)

MCP Integration (AI Agents)

Add to your Kiro/Claude agent config:

{
  "mcpServers": {
    "knowledge": {
      "command": "km-server"
    }
  }
}

Your AI agent gets these tools:

  • search — semantic search with graph context

  • blast_radius — dependency analysis

  • check_conventions — verify code follows team patterns

  • index_repo — add new repos to the knowledge base

Architecture

┌─────────────────────────────────────────────────┐
│                  Your AI Agent                    │
│              (Kiro / Claude / Cursor)             │
└────────────────────┬────────────────────────────┘
                     │ MCP Protocol
┌────────────────────▼────────────────────────────┐
│              Knowledge Master                    │
│                                                  │
│  ┌──────────┐  ┌────────────┐  ┌────────────┐  │
│  │  Search  │  │Blast Radius│  │ Conventions│  │
│  └────┬─────┘  └─────┬──────┘  └─────┬──────┘  │
│       │               │               │         │
│  ┌────▼───────────────▼───────────────▼──────┐  │
│  │            FalkorDB (Graph + Vector)       │  │
│  │                                           │  │
│  │  [Repo]──USES_TECH──▶[Tech]              │  │
│  │    │                                      │  │
│  │    ├──DEFINES_SERVICE──▶[Service]         │  │
│  │    │                      │               │  │
│  │    ├──FOLLOWS──▶[Convention]              │  │
│  │    │                                      │  │
│  │  [Person]──AUTHORED──▶[Document]          │  │
│  │                          │                │  │
│  │                    [Chunk + Embedding]     │  │
│  └───────────────────────────────────────────┘  │
│                                                  │
│  ┌───────────────────────────────────────────┐  │
│  │         Ollama (nomic-embed-text)          │  │
│  └───────────────────────────────────────────┘  │
└──────────────────────────────────────────────────┘

Commands

Command

Description

km start

Boot Docker + pull embedding model

km stop

Stop containers

km index <path>

Index a git repo or docs directory

km search <query>

Semantic search with re-ranking

km blast-radius <target>

Multi-layer dependency analysis

km safe-to-change <target>

Risk assessment (safe/risky/dangerous)

km who-owns <file>

File ownership (git blame, recency-weighted)

km check-conventions <path>

Verify code follows detected patterns

km connect <source>

Pull from external MCP (email, Slack)

km setup <tool>

Auto-configure MCP for AI tools

km watch <path>

File watcher with auto re-index

km upgrade

Migrate graph schema

km prune

Remove stale/orphaned data

km changelog

Generate CHANGELOG.md

km list

Show indexed repos, techs, stats

km remove <name>

Remove a source

km serve

Start web UI at http://127.0.0.1:9999

km status

Check system health

What gets extracted automatically

When you index a repo, Knowledge Master detects:

Category

Examples

Tech stack

Languages, frameworks, packages from dependency files

Services

From docker-compose.yml and K8s manifests

Dependencies

Service-to-service relationships

Conventions

File naming (snake_case/kebab-case), folder structure, design patterns

People

Git commit authors and file ownership

Code structure

Functions, classes, chunked by AST-aware boundaries

Feature Status

Feature

Status

Notes

Semantic search + re-ranking

✅ Stable

Two-pass retrieval with confidence scoring

Knowledge graph (FalkorDB)

✅ Stable

Nodes, edges, vector index, schema versioning

CLI (14 commands)

✅ Stable

start, index, search, blast-radius, safe-to-change, who-owns, etc.

MCP server (8 tools)

✅ Stable

search, blast_radius, safe_to_change, who_owns, check_conventions, index, status

REST API

✅ Stable

/api/v1/ with OpenAPI docs

Web UI + graph viz

✅ Stable

htmx + D3, search, file browser, graph

Git repo indexing

✅ Stable

Parses code, extracts authors, detects tech stack

Multi-language static analysis

✅ Stable

Python (ast), TypeScript, Go, Rust (tree-sitter)

Blast radius (multi-layer)

✅ Stable

Imports → services → people, confidence levels

safe-to-change risk assessment

✅ Stable

Blast radius + test coverage = risk score

Git blame ownership

✅ Stable

Recency-weighted (3x/2x/1x)

Schema migrations

✅ Stable

Auto-migrate, km upgrade

Deduplication

✅ Stable

Content hash, skips unchanged

Convention detection

⚡ Basic

Folder structure + file naming patterns

Email connector (ms-365)

🧪 Experimental

Works, requires external MCP setup

km watch

🧪 Experimental

Polling-based, may change

Legend: ✅ Stable — ⚡ Basic (works, limited scope) — 🧪 Experimental (may change)

Comparison

Feature

Knowledge Master

Generic RAG

GitHub Copilot

Glean

Graph relationships

✅

❌

❌

Partial

Blast radius analysis

✅

❌

❌

❌

Convention enforcement

✅

❌

❌

❌

Local-first (no cloud)

✅

✅

❌

❌

MCP integration

✅

❌

❌

❌

Multi-repo intelligence

✅

Partial

❌

✅

Cost

Free

Free

$19/mo

$15-30/mo

Development

# Run tests
pytest

# Lint
ruff check knowledge_master/

# Run MCP server directly
python -m knowledge_master.server

# Run CLI directly
python -m knowledge_master.cli status

Security

Knowledge Master runs entirely on your machine. No data leaves localhost.

  • All ports bound to 127.0.0.1 (not accessible from LAN)

  • Ollama runs locally — no cloud API calls

  • MCP server uses stdio (no network exposure)

  • Optional API key auth for REST endpoints

# Enable API key auth
export KM_API_KEY=$(openssl rand -hex 32)
km serve

See SECURITY.md for full security model, risks, and hardening guide.

Troubleshooting

Issue

Fix

km start fails with "Docker not running"

Start Docker: colima start (macOS) or sudo systemctl start docker (Linux)

km start fails with "Ollama not found"

Install Ollama from https://ollama.com and run ollama serve

km index is slow

First run downloads the embedding model (~274MB). Subsequent runs are fast.

Web UI shows "Connection refused"

Make sure containers are running: km start

Search returns poor results

Index more content. Quality improves with more context in the graph.

Port 9999 already in use

Use km serve --port 8888

License

MIT

Available Tools

8 tools
blast_radiusA

Show what depends on a target (service, tech, or file). Returns all entities that would be affected by changing the target.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesService name, technology, or file to check dependencies for

TDQS

A3.6/5.0
Behavior3/5

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

No annotations are provided. The description implies a read-only operation (showing dependencies) but does not explicitly state that it does not modify anything. It lacks details about potential performance impact, caching, or required permissions.

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?

Two sentences with no extraneous information. The first sentence states the action and target scope, the second clarifies the return value. Every word earns its place.

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 tool with one parameter and no output schema, the description is quite complete. It explains the input and what the output represents. However, it could specify the output format (list, tree, etc.) for greater 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 coverage is 100%, so the baseline is 3. The description adds context (returns affected entities) beyond the parameter description, but does not provide additional constraints or formatting details.

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 tool's purpose: 'Show what depends on a target (service, tech, or file)'. The verb 'Show' and resource 'dependencies' are specific, and it distinguishes from sibling tools like 'check_conventions' and 'search' by focusing on impact analysis.

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 its siblings. It does not mention prerequisites, limitations, or alternative tools.

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

check_conventionsB

Check if a repo or path follows the detected coding conventions (naming, structure, patterns). Returns pass/fail for each convention.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to repo or directory to check

TDQS

B3.3/5.0
Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'Returns pass/fail for each convention', omitting critical behavioral traits like destructiveness, authentication needs, or rate limits. Lacks depth for a mutation-free check.

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?

Single sentence, no fluff. Efficient but extremely minimal; could benefit from slight restructuring or additional context without becoming verbose.

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 single parameter, no output schema, and no annotations, the description adequately covers the tool's purpose and return format. However, missing details about what 'conventions' are detected or how they are determined, but acceptable for basic usage.

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% (one parameter with description). Description adds no new meaning beyond the schema, which already explains 'path' as a directory/repo path. Baseline 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?

Description clearly states verb 'Check' and resource 'repo or path follows detected coding conventions'. Differentiates from siblings like index_repo (indexing) and search (general search) by specific convention-checking purpose.

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 explicit guidance on when to use this tool versus alternatives. Description implies use for checking conventions but does not mention exclusions or prerequisites, leaving the agent to infer context.

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

get_statusA

Get knowledge base statistics: number of chunks, documents, repos indexed.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It accurately describes the tool as non-destructive ('Get... statistics'), but does not mention potential issues like rate limits or authorization. For a read-only tool, this is adequate but could be improved.

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 that is front-loaded with the verb and resource, efficiently conveying the tool's purpose without unnecessary words.

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 tool has no parameters and no output schema, the description sufficiently explains what the tool returns (number of chunks, documents, repos indexed). It covers the essential information for a simple status tool.

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 no parameters, so schema description coverage is 100% trivially. The description does not need to add parameter semantics, and the baseline of 4 applies as there is nothing to improve.

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 'Get' and the resource 'knowledge base statistics', listing specific items included (number of chunks, documents, repos indexed). It effectively distinguishes from sibling tools like index_directory and search, which have different purposes.

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?

While no explicit when-to-use or alternatives are given, the simplicity of the tool and its distinct purpose from siblings make the usage context clear. It implies it should be used to retrieve overall knowledge base statistics.

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

index_directoryB

Index markdown/text files from a directory.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesDirectory path to index
patternsNoGlob patterns (default: *.md, *.txt)

TDQS

B3.2/5.0
Behavior2/5

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

The description lacks any behavioral details beyond the basic action. No mention of side effects, permissions, or whether the index is persistent or ephemeral. With no annotations, 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.

Conciseness5/5

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

Single sentence, front-loaded, no unnecessary words. Efficient and clear.

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?

Without an output schema, the description should explain the result or effect of indexing. It does not mention return type, success state, or any side effects.

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%, providing clear param definitions. The description adds minimal value beyond the schema, only restating that files are markdown/text.

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 tool indexes markdown/text files from a directory, with a specific verb and resource. It distinguishes from sibling tools like 'index_repo' which likely handles full repositories.

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 on when to use this tool versus alternatives like index_repo or search. The description does not specify context or prerequisites.

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

index_repoB

Index a git repository into the knowledge graph. Parses code files, extracts authors, builds relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
pathYesPath to git repository
branchNoBranch to indexHEAD

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries full burden. It discloses that the tool parses code files, extracts authors, and builds relationships, but lacks details on side effects (e.g., whether indexing is incremental or full rebuild), idempotency, resource usage, or required permissions. Some transparency, but significant gaps remain.

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?

Description is concise (two sentences) and front-loaded with the main purpose. Could be slightly more structured (e.g., bullet points for effects), but no wasted words.

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?

Given 2 parameters, no output schema, and no annotations, the description lacks details on return value, success/failure indications, error conditions, and behavior on large repos. It is adequate for a simple tool but not fully complete.

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 descriptions for both 'path' and 'branch'. Description adds no extra meaning beyond what the schema provides. Baseline score of 3 is appropriate as the schema already addresses parameter semantics adequately.

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 tool indexes a git repository into the knowledge graph, parsing code files and extracting authors and relationships. It specifies the resource (git repository) and action (index), and distinguishes from similar tools like index_directory which indexes generic directories.

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 explicit guidance on when to use this tool vs alternatives like index_directory or search. Does not mention prerequisites (e.g., git must be installed) or scenarios where it should be avoided (e.g., large repos with performance concerns).

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

safe_to_changeC

Assess risk of changing a target. Returns risk level, blast radius, and test coverage.

ParametersJSON Schema
NameRequiredDescriptionDefault
targetYesFile or module to assess

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 must convey behavioral traits. It does not indicate whether the tool is read-only, has side effects, or requires any authorizations. The mention of 'risk level, blast radius, test coverage' is useful but insufficient for full transparency.

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 sentence that conveys the core purpose. It is concise and front-loaded, but could be expanded slightly without losing conciseness (e.g., adding behavioral details).

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?

Given the low complexity (1 param, no output schema, no nested objects), the description provides the basic outcome but lacks details on return format or how to interpret the results. It is adequate but not fully complete.

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 single parameter 'target' has 100% schema coverage with description 'File or module to assess'. The tool description repeats 'File or module' without adding new semantics 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.

Purpose4/5

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

The description clearly states the tool assesses risk of changing a target and specifies the returned information (risk level, blast radius, test coverage). However, it does not differentiate from sibling tools like 'blast_radius', which may overlap in functionality.

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 such as 'blast_radius'. No when-not-to-use or context for selection is given.

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

who_ownsB

Find who owns a file based on OWNS relationships in the graph.

ParametersJSON Schema
NameRequiredDescriptionDefault
fileYesFile path to check ownership

TDQS

B3.4/5.0
Behavior2/5

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

No annotations exist, so description carries full burden. It does not disclose key traits like read-only nature, permissions needed, or graph complexity. The OWNS relationship mention adds minimal insight.

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?

Single sentence is concise and focused. However, could be slightly more informative without adding length.

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?

No output schema, so description should indicate return value format. It does not specify whether result is a person name, user ID, etc., leaving ambiguity.

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 a clear parameter description. Description adds OWNS context, but baseline score is appropriate since schema already covers the parameter.

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?

Description clearly states the tool finds who owns a file using OWNS relationships, with a specific verb and resource. It is distinct from sibling tools like blast_radius or check_conventions.

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?

No guidance on when to use this tool vs alternatives. While purpose is clear, no explicit when-not or context for choosing over siblings.

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. 2 tool updatesv0.5.0
    • Addedsafe_to_change
    • Addedwho_owns
  2. 6 tool updatesv0.1.0
    • First observedblast_radius
    • First observedcheck_conventions
    • First observedget_status
    • First observedindex_directory
    • First observedindex_repo
    • First observedsearch
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: indexing, searching, impact analysis, ownership, conventions checking. Even similar tools like blast_radius and safe_to_change are differentiated by depth of analysis.

Naming Consistency4/5

Tools use snake_case consistently. Most follow verb_noun pattern (index_directory, check_conventions), but some are noun-based (blast_radius, safe_to_change). Still predictable and readable.

Tool Count5/5

8 tools is well-scoped for a knowledge management server. Each tool covers a core function without redundancy or bloat.

Completeness4/5

Covers indexing, search, impact analysis, conventions checking, and ownership. Missing delete or update operations for indexed data, but core read-oriented workflows are complete.

Maintenance

ActivityStale
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

  • Graph-Mem MCP

    Sathvik-1007
    A
    license
    Not graded
    quality
    A
    maintenance
    A universal MCP server providing persistent, structured memory through a knowledge graph with graph storage, semantic vector search, and multi-hop traversal for AI agents and IDEs.
    1
    MIT

  • codemap

    abdul-hamid-achik
    A
    license
    Not graded
    quality
    A
    maintenance
    MCP server for local-first code intelligence, providing structural code graph, semantic search, and impact analysis to AI agents.
    2
    MIT

  • Mnemograph

    tm42
    A
    license
    A
    quality
    D
    maintenance
    A persistent, event-sourced knowledge graph MCP server for AI coding agents that enables semantic search, tiered context retrieval, and git-based version control of AI memory.
    31
    2
    MIT

  • LAIN-mcp

    spuentesp
    A
    license
    Not graded
    quality
    A
    maintenance
    A persistent code-intelligence MCP server that builds a queryable knowledge graph of your codebase, enabling AI assistants to perform cross-file structural reasoning, dependency analysis, and blast radius detection.
    6
    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/subzone/knowledge-master'

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