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., "@MCP Knowledge Bridge search for artificial intelligence trends"
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.
手写、可教学的 MCP 子集实现。v0.3.0 在 stdio 上支持 2025-11-25 协议协商，以及 tools / resources / prompts / ping 与初始化生命周期。体积刻意保持小，不是完整 MCP SDK，也不是生产网关。
python -m pip install -e ".[dev]"
python -m examples.demo_protocol
python -m mcp_bridge.serverstdio 传输：每行一条 UTF-8 JSON-RPC（非 Content-Length 分帧）。
mcp-knowledge-bridge{
"mcpServers": {
"knowledge-bridge": {
"command": "python",
"args": ["-m", "mcp_bridge.server"],
"cwd": "/absolute/path/to/mcp-knowledge-bridge"
}
}
}Related MCP server: Alcove
mcp_bridge.http_server 是带鉴权的 自定义 REST 伴生服务。
它不是 MCP Streamable HTTP，也不实现 MCP-over-HTTP / OAuth。
export MCP_BRIDGE_TOKEN="replace-with-a-secret"
mcp-knowledge-bridge-rest
curl -H "Authorization: Bearer replace-with-a-secret" http://127.0.0.1:8765/toolsPowerShell：
$env:MCP_BRIDGE_TOKEN = "replace-with-a-secret"已实现：initialize、notifications/initialized、ping、tools/list、tools/call、resources/list、resources/read、prompts/list、prompts/get。
未声称：sampling、roots、elicitation、subscriptions、Streamable HTTP 等。
python -m ruff check .
python -m pytest --cov=mcp_bridge --cov-report=term-missingMIT © Brian20040323
Echo payload for wiring tests.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present; description does not state that tool returns the input message or any side effects. Transparency insufficient for a tool with no output schema.
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?
Extremely concise at 5 words, but front-loads purpose. Could add minimal behavioral detail without sacrificing 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?
For a single-parameter debug tool, description is minimally adequate but lacks output expectation. Given low complexity, a 3 is appropriate.
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 0% and description only refers to 'payload' without clarifying the 'message' parameter's format, constraints, or purpose beyond echoing.
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?
Description clearly states verb 'echo' and resource 'payload' with specific purpose 'wiring tests'. Distinguishes from sibling knowledge base 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?
Implies usage during 'wiring tests' but no explicit when-to-use or alternatives provided. Standard debug tool context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compare two knowledge topics and return a structured diff summary.
| Name | Required | Description | Default |
|---|---|---|---|
| left_id | Yes | ||
| right_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions 'return a structured diff summary' but does not disclose read-only/destructive nature, error handling (e.g., missing IDs), or permission requirements. The behavior beyond the stated action is opaque.
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 concise sentence that communicates the core function. It is well-structured and front-loaded. Minor points off for not including additional helpful details, but no extraneous words.
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 two required parameters, no output schema, and no annotations, the description is insufficient. It does not explain what 'structured diff summary' means, how results are formatted, or any edge cases. A more complete description would include return structure and behavior.
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 0%, and the description does not explain the parameters 'left_id' and 'right_id' beyond implying they identify knowledge topics. No addition of format, constraints, or role. The agent must guess from parameter names.
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 uses a specific verb ('Compare') and resource ('knowledge topics') and indicates the output ('structured diff summary'). It clearly states the tool's purpose but does not explicitly distinguish it from sibling tools like kb_search or kb_get, though the action is distinct.
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 no explicit guidance on when to use this tool versus alternatives. It does not state prerequisites, context, or when not to use it. The agent is left to infer usage from the action verb alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one knowledge entry by id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
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 does not mention side effects, authentication requirements, error scenarios (e.g., missing ID), or any other behavioral traits beyond the basic fetch operation. This is insufficient for an agent to understand the tool's full impact.
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, short sentence that is front-loaded with the verb and resource. Every word serves a purpose, and there is no unnecessary information. It is appropriately concise for a simple retrieval tool.
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 one parameter and no output schema, the description is adequate for a basic retrieval but lacks completeness. It does not explain the return format, error handling, or provide any additional context that would help the agent use it effectively, especially compared to the sibling tools. It meets the minimum 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?
The input schema has 0% description coverage for parameters, so the description must add meaning. However, it only repeats 'by id' without explaining the format, constraints, or expected values of the 'id' parameter. This adds little value beyond what the schema already provides.
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 uses the verb 'Fetch' and specifies the resource 'knowledge entry' and the method 'by id', clearly distinguishing from siblings like kb_search (which searches without a specific id) and kb_compare. It leaves no ambiguity about what the tool does.
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 does not provide any explicit guidance on when to use this tool versus alternatives, such as kb_search or kb_compare. The context is implied (use when you have an ID), but no direct comparison or exclusion is stated, making it less helpful for an AI agent to decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
BM25 search over local knowledge entries and markdown docs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| top_k | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions the search algorithm (BM25) and scope. Missing details on read-only nature, pagination, result limits, or handling of no results.
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?
Single sentence, front-loaded, no fluff. Could add more context without sacrificing 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?
With 2 parameters, no output schema, and no annotations, the description is too sparse. Agent needs to know return format, pagination, and failure modes for effective 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 coverage is 0%, and description adds no meaning beyond parameter names. 'query' and 'top_k' are self-explanatory but not elaborated. Default value for top_k (3) is in schema but not described.
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 (BM25 search) and resource (local knowledge entries and markdown docs). It distinguishes from sibling tools like kb_get (retrieve single entry) and kb_compare (compare entries).
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 BM25 search but provides no explicit when-to-use, when-not-to-use, or alternatives. Sibling tools offer indirect guidance but are not mentioned.
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.0echo_debugkb_comparekb_getkb_searchEach tool has a clearly distinct purpose: search, fetch by ID, compare two topics, and a debug echo. No overlap in functionality.
Three tools follow the 'kb_' prefix with verbs, but 'echo_debug' breaks the pattern by omitting the prefix. Mixed conventions reduce consistency.
Four tools is well within the typical 3-15 range and feels appropriate for a focused knowledge bridge server.
Only read and compare operations are present. Missing create, update, and delete for knowledge entries, which are essential for managing a knowledge base.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory and actions for Claude, Kiro, OpenAI, Cursor, and other MCP-compatible AI clients.
Agent-native notes, tasks, dev-docs, vaults, sync & handoffs. MCP + OpenAPI dual surface.
Portable memory for AI agents: capture once, recall across Claude, Cursor, and any MCP client.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Brian20040323/mcp-knowledge-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
