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., "@engineering-knowledge-mcp search our knowledge base for API authentication setup"
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.
A very lightweight local MCP server that gives coding agents (Claude Code, GitHub Copilot, etc.) a shared engineering knowledge base to search and update — internal conventions, API details, infra config, auth flows, local dev setup, and so on.
Knowledge lives as plain Markdown files in this Git repo. The MCP server is a thin, stateless read/write layer over the filesystem — nothing more.
Coding agents can search the knowledge base instead of guessing at internal conventions or asking the user to repeat themselves.
Agents can capture new facts with almost no friction (one tool call, no need to know where the fact belongs).
Agents can create and update structured knowledge documents deterministically.
Everything is Markdown in Git, so it's useful even without the MCP server — grep it, read it, edit it, review diffs, commit it, PR it, exactly like code.
Related MCP server: bikky
engineering-knowledge-mcp/
├── knowledge/ # the knowledge base itself (Markdown, organized by topic area)
│ ├── api/
│ ├── cloud/
│ ├── data/
│ ├── frontend/
│ └── general/
├── inbox/
│ └── knowledge-inbox.md # low-friction capture target; triage manually into knowledge/
├── src/
│ ├── index.ts # MCP server entrypoint (stdio transport)
│ ├── paths.ts # path sanitization / traversal protection
│ ├── knowledge.ts # search, get, create, update, capture logic
│ └── tools/index.ts # MCP tool registration + input schemas
├── test/ # node:test unit tests
├── CLAUDE.md # agent instructions auto-loaded by Claude Code when working in this repo
├── package.json
└── tsconfig.jsonDesign choices, deliberately:
MCP over stdio only. No HTTP server, no Express — the client (Claude Code, Copilot, MCP Inspector) spawns this process and talks JSON-RPC over stdin/stdout.
No database, no embeddings, no vector store. Search is case-insensitive token matching over Markdown sections, computed on demand. This is fine at the scale of tens-to-hundreds of small documents, and it means there's no index to keep in sync with the files on disk — the files are the source of truth, always.
No in-memory index, no filesystem watching. Every tool call reads what it needs from disk at call time. Simpler, and cheap at this scale.
No automatic git commits. Tool calls only touch the working tree. Review and commit/push are up to you. (The design leaves room to add auto-commit or PR creation later without changing the tool contracts.)
The brief mentioned @modelcontextprotocol/server; the actual published package is
@modelcontextprotocol/sdk
(v1.30+), which is what this project uses (McpServer + StdioServerTransport).
Each document is a Markdown file under knowledge/<area>/<topic>.md, with optional
minimal frontmatter:
---
title: APIM
tags:
- api
- apim
---
# APIM
## Base paths
Internal modelling APIs use ...
## Authentication
...
## Local development
...No required schema beyond that — frontmatter is optional, headings are just normal
Markdown ## sections. search_knowledge and update_knowledge use ##-level (and
deeper) headings as the unit of a "section," so structuring documents with clear
headings makes both search results and updates more precise.
Captured-but-untriaged knowledge goes to inbox/knowledge-inbox.md as timestamped
entries. Periodically (by hand, or by asking an agent to help) move/organize entries
from the inbox into proper knowledge/ documents.
Requires Node.js 20+.
npm install
npm run build
npm startFor local iteration (runs directly from TypeScript via tsx, no build step):
npm run devBoth start the server on stdio and wait for a client to connect — you won't see protocol traffic on the terminal; only startup/diagnostic logs (written to stderr, never stdout, since stdout is reserved for MCP protocol messages).
Interactive UI:
npx @modelcontextprotocol/inspector npm run devThis opens a browser UI where you can call search_knowledge, list_knowledge_topics,
get_knowledge, capture_knowledge, create_knowledge, and update_knowledge by
hand and inspect their JSON Schemas and responses.
Non-interactive / scriptable:
npx @modelcontextprotocol/inspector --cli node dist/index.js --method tools/list
npx @modelcontextprotocol/inspector --cli node dist/index.js \
--method tools/call --tool-name search_knowledge --tool-arg query="apim authentication"Claude Code / most MCP clients use a config block like:
{
"mcpServers": {
"engineering-knowledge": {
"command": "node",
"args": ["/absolute/path/to/engineering-knowledge-mcp/dist/index.js"]
}
}
}For GitHub Copilot's MCP support, use the equivalent command/args stdio server
entry in its MCP configuration file. Run npm run build first so dist/index.js
exists, or point command/args at npx tsx /absolute/path/to/src/index.ts to run
from source directly.
This repo ships a CLAUDE.md with the instruction below, which Claude Code loads automatically whenever it's working inside this repo. For other clients (Copilot, etc.), add the equivalent instruction to their system prompt / instructions file:
Before asking the user about internal engineering conventions, infrastructure, APIs, authentication, platform configuration, or established development patterns, search the engineering knowledge MCP. Do not invent internal configuration values. If the user explicitly asks to remember, capture, or add durable engineering knowledge, use the knowledge MCP write tools.
Tool-by-tool guidance:
search_knowledge(query) — first stop for "how do we usually...", "what's our
convention for...", "what's the base URL / auth flow for...". Returns ranked
sections with file paths, not whole documents. Also searches not-yet-triaged
entries in inbox/knowledge-inbox.md, so a recent capture is findable even
before it's been filed under a proper topic. Among documents that already match
on body/heading text, one whose frontmatter tags also match a query word
ranks higher — tags boost ranking, they don't create a match on their own.
list_knowledge_topics() — no arguments; lists every document's path, title,
and tags without full content. Use this to browse what exists when you don't have
a good search term yet, or to check whether a topic already exists before calling
create_knowledge.
get_knowledge(topicOrPath) — once you know (or search_knowledge told you)
which document you want, fetch it in full. Accepts loose references: "apim",
"api/apim", or "knowledge/api/apim.md".
capture_knowledge(content, suggestedTopic?) — use when the user says
"remember this" / "note that" / states a fact worth keeping, and you don't want to
make them figure out where it belongs. It just appends to the inbox.
create_knowledge(topic, title, content) — use when adding a genuinely new
topic that doesn't exist yet. Fails loudly if the topic already exists (use
update_knowledge instead).
update_knowledge(topicOrPath, heading, content, mode) — the deliberately
not natural-language write tool. See the design note below.
update_knowledge takes heading + mode instead of a free-text changeThe brief flagged this as something needing careful design: the goal is for the
agent (which has an LLM) to decide what a natural-language change means, not for
this server to run its own AI interpretation of instructions. So update_knowledge
takes a structural, deterministic target instead:
topicOrPath — which document.
heading — the exact ##/###/etc. heading text identifying a section. If it
doesn't exist, a new ## section with that heading is appended at the end of the
document (so updates never silently fail against slightly-stale documents).
content — the literal Markdown to write.
mode: "append" (default) adds content to the end of the section, "replace"
overwrites the whole section body.
This means the calling agent is expected to have already turned "update the
local-dev section to mention the new port" into concrete Markdown content and picked
append/replace — exactly the kind of judgment call an LLM-backed client is
positioned to make, and exactly the kind of judgment call this lightweight server
should not be making from a raw string.
If you already have notes somewhere (a personal wiki, a folder of .md files, a
Notion export, a big "tribal knowledge" doc, Slack threads you've saved, etc.), there's
no import tool and no special format to convert to — this is deliberately just a
folder of Markdown files. Two ways to get started, roughly in order of how much of
your existing structure is worth preserving:
A. Drop files in directly (best when your notes are already reasonably organized)
Copy your existing .md files into knowledge/, sorted into whichever of
api/ cloud/ data/ frontend/ general/ fits best (or add new topic folders —
nothing enforces the initial five).
Add minimal frontmatter (title, optionally tags) to each if it doesn't have
any — not required, but it's cheap and get_knowledge/search results read better
with a title.
Break very long documents into headed ## sections if they aren't already —
search_knowledge and update_knowledge both operate at the heading level, so a
10,000-word single-section wall of text will search/update worse than the same
content split under a few clear headings.
Run npm test (sanity check nothing broke) and try a few search_knowledge /
get_knowledge calls via the Inspector (§5) against your real content.
Review the diff and commit it yourself, same as any other change to this repo.
B. Let an agent do the migration for you (best for messy/unstructured source material)
Point Claude Code (or another coding agent, once this MCP is configured for it) at your existing notes and ask it to migrate them using the write tools. For example:
I have engineering notes in
~/notes/engineering/. Read through them and usecreate_knowledgeto turn them into proper documents underknowledge/, grouped by topic. Where something doesn't cleanly fit an existing topic, usecapture_knowledgeinstead so it lands in the inbox for me to review.
This works well because turning messy prose into "a title, some tags, a few clear
## sections" is exactly the kind of judgment call an LLM-backed agent is good at —
the same reasoning behind why update_knowledge pushes that judgment to the caller
rather than the server (see §7). The agent still can't write outside knowledge//
inbox/, and every resulting file shows up as a normal untracked/modified file for
you to review before committing — nothing is auto-committed.
Either way, treat the first pass as a rough draft: it's fine (expected, even) to
have capture_knowledge produce a long inbox you triage over a few sessions rather
than trying to get a perfect taxonomy up front.
All reads/writes are restricted to knowledge/ and inbox/ under the repo root.
Every caller-supplied path goes through safeResolve (src/paths.ts), which
rejects absolute paths, .. traversal, null bytes, and anything that resolves
outside the allowed directory.
create_knowledge sanitizes the topic into a safe filename segment before use.
No document content is ever executed, evaluated, or shelled out to.
No tool ever runs a shell command based on MCP input.
Errors are explicit (e.g. "no knowledge document found matching X") rather than falling back to guesses.
Low-friction capture of a durable engineering fact or convention, e.g. 'When testing the modelling API locally, X must be set to Y.' Appends a timestamped entry to inbox/knowledge-inbox.md for later triage into knowledge/. Does not require knowing where the information belongs. Use when the user explicitly asks to remember, capture, or add durable engineering knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The knowledge to capture, in plain language | |
| suggestedTopic | No | Optional hint about where this might eventually belong |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure, and it succeeds: it states that it appends a timestamped entry to a specific file (inbox/knowledge-inbox.md) and that the entry is for later triage into knowledge/. It also clarifies that it does not require knowing where the information belongs, setting correct expectations. It could mention potential effects (e.g., file creation or append behavior) but the essential behavior is transparent.
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, well-structured sentence followed by an example and a usage directive. It front-loads the core purpose, provides a concrete illustration, and adds the usage trigger without any filler. Every element earns its place, and the whole fits comfortably in a readable length.
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 tool with only two parameters, one required, no output schema, and no nested structures, the description is fully sufficient. It covers what the tool does, where it writes, when to use it, and the key benefit (low friction). Nothing an agent needs to correctly invoke this tool is missing.
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?
Although the schema already documents both parameters at 100% coverage, the description adds meaningful semantic context. It explains that content is a durable engineering fact or convention, gives an example, and clarifies that suggestedTopic is optional because the tool does not require knowing the target location. This goes beyond mere schema repetition and helps an agent understand how both fields interact.
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 a specific verb ('capture'), a target resource (durable engineering knowledge appended to inbox/knowledge-inbox.md), and a clear distinction from direct knowledge creation. It includes a concrete example that helps an agent immediately recognize what counts as appropriate input, and the sibling list (create_knowledge) reinforces the uniqueness of this tool as an inbox capture.
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 explicit guidance on when to use the tool: 'Use when the user explicitly asks to remember, capture, or add durable engineering knowledge.' It also explains the benefit ('Does not require knowing where the information belongs'), which implicitly signals that create_knowledge is the alternative when topic placement is known. However, it does not explicitly list when-not-to-use conditions or name sibling alternatives, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Markdown knowledge document under knowledge/.md. Fails if a document already exists at that path (use update_knowledge instead). Topic paths are sanitized and cannot escape the knowledge directory.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Document title, used in frontmatter and as the H1 if content has none | |
| topic | Yes | Topic path, e.g. 'api/graphql' or 'cloud/gcp' | |
| content | Yes | Markdown body content |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing the fail-if-exists behavior, path sanitization, and containment within the knowledge directory. It does not mention the success return value or authorization requirements, but those are secondary for a create operation with this level of detail.
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?
Three sentences with no filler: the main action is front-loaded, the failure condition follows immediately, and the alternative tool is named without extra prose. Every sentence contributes essential information.
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?
The description is complete for a simple create tool: it covers purpose, path behavior, failure mode, and the key alternative. The only minor gap is not describing what a successful response looks like, but the absence of an output schema makes that less critical.
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 the schema already documents all three parameters. The description adds useful context for topic by explaining the knowledge/<topic>.md mapping and sanitization, but it does not significantly expand on title or content beyond what the schema already says.
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 names the specific action (create), the resource (Markdown knowledge document), and the exact storage location (knowledge/<topic>.md). It also explicitly contrasts itself with update_knowledge by stating the failure condition when the document already exists.
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?
It clearly says to use update_knowledge instead when a document already exists, which gives an explicit create-vs-update routing rule. It does not explicitly contrast itself with capture_knowledge, but the failure-on-existing condition makes the intended use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full content of a specific knowledge document by topic or path. Accepts loose references such as 'apim', 'api/apim', or 'knowledge/api/apim.md'.
| Name | Required | Description | Default |
|---|---|---|---|
| topicOrPath | Yes | Topic name or relative path, e.g. 'apim' or 'api/apim' |
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 clearly indicates it is a read operation ('Retrieve'), which implies no side effects. However, it does not disclose details like error handling (e.g., behavior when topic is not found), authentication requirements, or rate limits. For a simple read tool this is adequate but not comprehensive.
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 exceptionally concise, with two sentences that front-load the primary purpose and then provide illustrative examples. Every word earns its place, with no filler or redundant content. This is ideal for efficient agent parsing.
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 tool with one parameter and no output schema, the description covers the essential aspects: what it does (retrieve full content) and what inputs it accepts. It does not specify the return format (e.g., markdown text) or any failure modes, but given the simplicity of the tool, this is not a significant gap. The description is sufficient for an agent to know how to invoke it correctly.
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?
Since schema coverage is 100%, the parameter is already well-documented in the schema with an example. The description adds value by explaining that loose references are accepted and provides additional format examples ('knowledge/api/apim.md'), which the schema does not cover. This goes beyond mere repetition and helps the agent understand the flexibility of the input.
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 the verb 'Retrieve' and the resource 'full content of a specific knowledge document', making the purpose unambiguous. It also distinguishes from siblings by focusing on retrieval of a specific document by topic/path, as opposed to search or list operations.
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 provides clear context on when to use the tool - when you have a specific topic or path - and gives concrete examples of accepted loose references. It does not explicitly name sibling tools or state when not to use it, but the implication is clear that this is for known references rather than discovery.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every knowledge document (path, title, tags) without full content. Use this to browse what topics exist before deciding what to search for, when a keyword search comes up empty, or to check whether a topic already exists before calling create_knowledge.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It implies a read-only operation (listing without side effects) and even mentions checking existence before creation, but it does not explicitly state 'read-only' or 'non-mutating'. It is clear enough, though not fully explicit.
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 two sentences and tightly packed with purpose, output details, and usage guidance. No unnecessary words or redundancy; it is efficiently structured.
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 simplicity of the operation (no parameters, no output schema), the description provides sufficient context: what it lists, what it omits, and when to use it. It covers the essential aspects for an agent to decide and invoke correctly.
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?
The input schema is empty, so there are no parameters to describe. The description adds no parameter-related information, but since schema coverage is 100% (empty), a 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 tool lists knowledge documents with their path, title, and tags, and explicitly excludes full content. It distinguishes from sibling tools by framing it as a browsing/pre-check operation, making its purpose 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 provides explicit use cases: browsing topics before searching, when keyword search returns empty, and before calling create_knowledge. This gives clear guidance on when to select this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search all engineering knowledge Markdown documents (and not-yet-triaged inbox captures) with simple case-insensitive text matching, boosted by frontmatter tag matches. Returns the strongest matching sections (not full documents) ranked by relevance, with file paths. Use this before asking the user about internal conventions, infra, APIs, auth, or platform config.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms, e.g. 'apim authentication' or 'aws s3 bucket policy' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the matching mechanism (case-insensitive text, tag boosting), the scope (including not-yet-triaged inbox captures), and the return format (sections with file paths). It does not mention potential side effects or limitations like rate limits, but the read-only nature is strongly implied by 'Search'.
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 concise and well-structured, consisting of two sentences that efficiently cover the tool's functionality, output, and usage context. There is no redundant or vague wording, and every clause contributes informational value.
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 absence of annotations and output schema, the description single-handedly provides sufficient context: it defines the search scope, matching behavior, return details, and a clear use-case. It also clarifies that it returns sections rather than full documents, which is crucial for an agent deciding between this and a document retrieval tool.
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?
The tool description adds meaning to the single 'query' parameter by explaining that it performs case-insensitive text matching and that tag matches boost results. This goes beyond the schema's example terms, giving the agent insight into how the query is interpreted.
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's function: searching all engineering knowledge Markdown documents, including inbox captures. It specifies the resource, the verb 'Search', and the output (sections with file paths), making it unambiguous and distinct from other potential tools.
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?
Explicit guidance is provided: 'Use this before asking the user about internal conventions, infra, APIs, auth, or platform config.' This tells the agent exactly when to invoke this tool, and the implicit contrast with retrieving full documents (sections vs. full documents) hints at 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.
Deterministically update an existing knowledge document by targeting a specific Markdown heading. This tool does NOT interpret natural-language change requests — the caller must decide what content to write and whether to append to the section or replace it. If the heading doesn't exist, a new section is appended at the end of the document.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | 'append' adds content to the end of the section; 'replace' overwrites the section body | append |
| content | Yes | Markdown content to write into the section | |
| heading | Yes | Exact heading text to target, e.g. 'Local development' | |
| topicOrPath | Yes | Topic name or relative path identifying the document |
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 discloses that the tool is deterministic, does not interpret natural language, targets a specific heading, and appends a new section if the heading is missing. This covers key operational behavior, though it does not mention permissions, error handling, or reversibility—acceptable for a low-risk knowledge document update.
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 three sentences, efficient and front-loaded with the core action. The key behavioral constraints (deterministic, no NL interpretation, heading behavior) are stated without unnecessary fluff.
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 simple update tool with 4 parameters, no output schema, and no annotations, the description covers the main operational aspects: target document, heading behavior, append/replace semantics, and the caller's responsibility. It lacks explicit mention of edge cases like handling invalid paths or partial failures, but these are not critical for a knowledge base update.
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 the schema already documents each parameter. The description adds value beyond the schema by explaining the heading-targeting behavior (exact text, and appending a new section if not found) and by clarifying that the caller must decide between append and replace, which maps to the mode parameter but is not fully explicit in the 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?
The description states a specific verb (update), resource (existing knowledge document), and a precise mechanism (targeting a Markdown heading). It explicitly distinguishes itself from natural-language change requests and implies it is not for creation, which differentiates it from siblings like create_knowledge and capture_knowledge.
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 clearly implies use for updating existing documents and clarifies it is deterministic, but it does not explicitly name alternatives or state when not to use it (e.g., for creating new docs, use create_knowledge). The behavioral note about appending a new section when heading is missing provides some context, but sibling differentiation is left implicit.
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.
v0.1.0capture_knowledgecreate_knowledgeget_knowledgelist_knowledge_topicssearch_knowledgeupdate_knowledgeAll six tools have distinct purposes: searching, listing, retrieving, capturing to inbox, creating new docs, and updating existing docs. No overlapping or ambiguous functions.
Tool names follow a consistent verb_noun pattern (search_knowledge, list_knowledge_topics, get_knowledge, capture_knowledge, create_knowledge, update_knowledge). Verbs clearly indicate actions and nouns correctly describe the target.
Six tools is a well-scoped number for a knowledge management server, covering search, browse, read, capture, create, and update without unnecessary redundancy.
The tool set covers create (capture and create), read (search, list, get), and update, but lacks a delete/remove operation. This is a minor gap since knowledge bases may need to retire outdated entries, but core workflow is supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted markdown project wikis your team's AI assistants read, search, and update over MCP.
Team docs served to AI agents over MCP - search, Markdown reads, version pinning, read audit.
Shared project wiki for AI agents: read and write pages, next actions, and activity logs over MCP.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/niallr12/engineering-knowledge-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
