knowledge-engine
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| MCP_HOST | No | Host interface to bind for the HTTP transport. Default 0.0.0.0. | |
| MCP_PORT | No | Port for the HTTP transport. Default 39010. | |
| GRAPH_URL | No | URL path for the knowledge graph page. Default /k/graph. | |
| LLM_MODEL | No | OpenRouter model identifier for LLM calls in the research tool. Default deepseek/deepseek-chat. | |
| RERANK_MODEL | No | FlashRank cross-encoder model name. Default ms-marco-MiniLM-L-12-v2. | |
| BRAVE_API_KEY | No | API key for Brave web search (primary backend for research tool). | |
| KNOWLEDGE_DIR | No | Path to the knowledge corpus root. Defaults to examples/seed-kb/. | |
| MCP_TRANSPORT | No | Transport mode: http or stdio. Default http. | |
| TAVILY_API_KEY | No | API key for Tavily web search (fallback backend). | |
| FLASHRANK_CACHE | No | Writable directory to store the downloaded reranking model. | |
| RERANK_DISABLED | No | Set to '1' to disable FlashRank reranking and use raw BM25. | |
| RERANK_CANDIDATES | No | Number of BM25 candidates to pass to the reranker. Default 50. | |
| OPENROUTER_API_KEY | No | API key from openrouter.ai. Required for the research tool (LLM synthesis). | |
| RESEARCH_MCP_TOKEN | No | Bearer token for authenticating requests to the server. If unset, the server is unauthenticated (warns). |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| query_knowledgeA | Search the AmiticIA knowledge base — current, dated, rank-ordered AI-agent
findings — for material relevant to CHECK THE SDK FIRST — this is the research-frontier layer, not the
how-to-build layer. If you are building an agentic feature, the proven 2026
pattern almost always already lives in your SDK's own docs (LangGraph via the
SCOPE — this KB covers only the fast-moving AI-engineering frontier (agents, LLMs, harnesses, evals, context engineering, agent security, AI coding tools, model capability/cost trends): the areas where your training is most likely stale. It is NOT for general/evergreen software architecture (CRM, omnichannel, helpdesk, classical patterns — answer those from your own knowledge) and NOT for library/framework/API docs (use Context7). If the question is one of those, prefer your own knowledge or Context7 over this KB. Args: question: what to look up. topic: optional filter — one of the known topic slugs (agent-architecture, agent-harness, context-engineering, coding-agents, capability-and-cost-trends, agent-security, methodology, evals-and-benchmarks). Returns JSON: {cards: [...], coverage: {count, newest, oldest}}. |
| researchA | Answer a decision question with grounded, current, cited evidence. Runs the full loop: searches the knowledge base, runs live web searches, fetches the top pages, and synthesizes a dated answer with DeepSeek-V3. Every claim is traced to a retrieved source. CHECK THE SDK FIRST — do NOT reach for this before checking whether the SDK
already ships the primitive you need. The default authority for "how do I
build this" is the SDK's own documented pattern (LangGraph via the
SCOPE — the fast-moving AI-engineering frontier (agents, LLMs, harnesses, evals, agent security, AI coding tools, model capability/cost trends), where current reality outruns your training. It is NOT for general/evergreen software architecture (CRM, omnichannel, helpdesk, classical patterns — you already know those) or library/API docs (use Context7). Sources discovered here are promoted back into the KB, so keeping questions on-frontier keeps the KB clean. Returns JSON: {answer, citations: [{url,title,date}], confidence,
retrieval_date, kb_coverage, warnings, sources_used}. Check |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: query_knowledge is a quick, free BM25 retrieval from the KB, while research runs a full loop with live web searches and synthesis. The descriptions explicitly cross-reference each other, telling the agent when to use which, so there is little risk of misselection.
The tool names follow different conventions: 'query_knowledge' uses a verb_noun snake_case pattern, while 'research' is a bare verb with no object prefix. With only two tools, the inconsistency is noticeable and breaks the expected pattern established by the first name.
Two tools is on the thin side for a knowledge engine. The server's scope is reasonably narrow (quick keyword search vs. deep research), so it is not egregiously underbuilt, but it clearly sits at the borderline where a few more specialized operations (e.g., listing topics, retrieving specific cards) could make the set feel more complete.
The surface covers the core workflows of querying the KB and running grounded research, with good attention to fallback guidance (check SDK first, scope restrictions). Minor gaps exist, such as no way to list valid topic slugs or browse the KB without a question, but these are workable and do not create dead ends.