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., "@sociableWiki how do I decide subagent fan-out width?"
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 public, agent-searchable knowledge base about AI-native software development — working with coding agents, designing harnesses, orchestrating subagents, evaluating LLM systems. These are my own working notes, curated and rewritten to stand on their own.
The name is the point: this wiki is sociable — it's built to be plugged into your agent, not just read by you. Browse it as plain markdown here, or connect it as an MCP server and let your AI search it while it works.
한국어 안내는 아래 한국어에 있습니다. 모든 문서는 영어(정본)와 한국어 두 버전으로 제공됩니다.
The repo ships a Model Context Protocol server.
No API keys, no external service — it reads the markdown in this repo and serves it
over three tools: search_knowledge, read_doc, list_topics.
Claude Code:
claude mcp add sociable-wiki -- npx -y github:endmoseung/sociableWikiAny MCP client (Claude Desktop, Cursor, …) — add to your MCP config:
{
"mcpServers": {
"sociable-wiki": {
"command": "npx",
"args": ["-y", "github:endmoseung/sociableWiki"]
}
}
}Then ask your agent things like "search the sociable-wiki for how to decide subagent
fan-out width" — it will call search_knowledge, then read_doc on the hit.
Tool | What it does |
| Full-text search over every doc. Works in English and Korean. |
| Read one doc in full by concept id. |
| Browse everything, grouped by area. |
Related MCP server: Tenjin MCP
Everything lives as plain markdown:
knowledge/ — English (canonical). Start at knowledge/index.md.
ko/ — Korean mirror, same paths.
Each doc is one concept — a single sharp claim or decision rule, with a bit of
frontmatter for search and a body that explains it. Concept ids are just the file
path without .md (ai-native/fan-out-scope-gate). Areas:
ai-native/ — agents, harnesses, orchestration, LLM evaluation, context management.
dev/ — general engineering that isn't AI-specific.
principles/ — durable judgment calls and design principles.
Docs derived from external sources (papers, posts, talks) carry a ## Sources
section; the analysis and framing are mine, the underlying findings are credited.
git clone https://github.com/endmoseung/sociableWiki
cd sociableWiki
npm install && npm run build
node mcp/dist/index.js # speaks MCP over stdioThis repo isn't just my notes — it's a template you can run as your own agent-searchable wiki. My 22 docs are the worked example; the structure, the skills, and the MCP server are yours to take.
# 1. clone (or use this repo as a GitHub template)
git clone https://github.com/endmoseung/sociableWiki my-brain && cd my-brain
# 2. install the get / set / new skills into whatever agent you use
npx sociablewiki install # detects .claude / .cursor in this project
# add --global to install into ~/.claude
# 3. make it yours (sets author, repo, MCP name; run once)
npx sociablewiki initThen your agent has three verbs (they work the same in Claude Code, Cursor, and any
agent that reads dist/universal/AGENTS.md):
Verb | Skill | What you say |
get |
| "search my wiki for how I decide fan-out width" |
set |
| "add this pattern to my wiki" |
new |
| "make this wiki mine" (clears my example content) |
new swaps my content out for an empty wiki wired to your name and repo. From there you
set your own concepts, point the repo at your own remote, and connect your own MCP
server — the same way people connect mine. Keep adding docs and it grows into your public
knowledge surface.
The skills carry a portable quality gate: they check required frontmatter, dead
relates links, duplicate ids, and (if you list your employer/internal names in
.sociablewiki/config.json) sweep for those so private context never lands in a public wiki.
AI 네이티브 개발에 관한 공개 지식 베이스입니다 — 코딩 에이전트와 일하는 법, 하네스 설계, 서브에이전트 오케스트레이션, LLM 시스템 평가. 제가 실제로 쓰며 정리한 노트를 골라내고 홀로 읽어도 이해되게 다시 썼습니다.
이름 그대로 이 위키는 sociable합니다 — 혼자 읽는 문서가 아니라 당신의 에이전트에 꽂아 쓰라고 만들었습니다. 여기서 마크다운으로 읽어도 되고, MCP 서버로 연결해 AI가 작업 중에 직접 검색하게 해도 됩니다.
Claude Code에 연결:
claude mcp add sociable-wiki -- npx -y github:endmoseung/sociableWikiAPI 키도, 외부 서비스도 필요 없습니다. 레포 안의 마크다운을 그대로 읽어 세 가지
도구(search_knowledge·read_doc·list_topics)로 제공합니다. 검색은 영어와
한국어 모두 됩니다. 모든 문서는 영어 정본과 한국어판이 짝을 이룹니다.
Code (the MCP server): MIT.
Knowledge content (knowledge/, ko/): CC BY 4.0 — share and adapt with attribution.
Author: Seungmo Kim · github.com/endmoseung
Overview of everything in the wiki: the human-curated topic map when present, otherwise a generated listing grouped by area. Good first call to see what's here.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains the two possible outputs (human-curated or generated) but lacks details on side effects, permissions, or rate limits. For a read-only listing, 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?
Two concise sentences with no redundancy. The critical information is front-loaded, and every phrase 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?
Given zero parameters, no output schema, and no annotations, the description is fairly complete. It explains what the tool returns and suggests a use case, though it could mention output format limitations.
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?
No parameters, so baseline is 4. The description adds value by explaining the output nature (curated vs generated), which helps the agent understand the result beyond the empty 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 clearly states the tool's purpose: providing an overview of wiki topics, either as a human-curated map or generated listing grouped by area. It effectively distinguishes from siblings (read_doc, search_knowledge) by positioning itself as an initial broad view.
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 explicitly suggests 'Good first call to see what's here,' indicating when to use it as a starting point. However, it does not explicitly exclude scenarios or reference alternatives, though sibling names imply better tools for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one knowledge doc in full by concept id (as returned by search_knowledge or list_topics). English is canonical; pass lang: 'ko' for the Korean version when available.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Concept id, e.g. 'ai-native/context-compaction' | |
| lang | No | Language (default en) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states it reads the full doc and mentions language availability, but does not cover potential issues like doc size limits, authentication needs, or response format.
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 concise sentences: the first conveys the core purpose, the second adds crucial language guidance. No wasted 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?
The description is adequate for a simple read tool, but lacks details on return format (e.g., JSON structure) and error handling (e.g., missing ID). Given no output schema, these omissions reduce completeness.
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%, but the description adds value by explaining the 'id' originates from sibling tools and that 'lang' defaults to 'en' with Korean variant available. This enriches the parametric understanding beyond 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 clearly states the tool reads a full knowledge doc by concept id, specifying the verb 'read' and resource 'knowledge doc'. It distinguishes from siblings by indicating the source of the ID (list_topics, search_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 provides clear context for when to use the tool: when you have a concept id from search_knowledge or list_topics. It also gives guidance on language parameter use. However, it lacks explicit exclusions or when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search over the sociableWiki knowledge base (AI-native development, agent/harness engineering, dev practice). Works in English and Korean. Returns ranked matches with concept ids — call read_doc with an id for the full text.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Only return docs carrying ALL of these tags | |
| limit | No | Max results (default 8) | |
| query | Yes | Search query (English or Korean) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the search is full-text, supports English and Korean, returns ranked matches with concept ids. However, it does not specify ranking criteria, case sensitivity, or wildcard support, leaving some behavioral aspects implicit.
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 extremely concise: two sentences that pack in the core purpose, domain context, language support, return format, and a clear next step. Every sentence earns its place with no extraneous 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?
Given the absence of an output schema, the description adequately explains that the tool returns ranked matches with concept ids and directs to read_doc for full text. However, it does not mention whether the tags parameter affects the search or how ranking works, but the schema covers tags. Overall, it is mostly complete for a search tool with good schema coverage.
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 each parameter already has a description. The tool description does not add new parameter-level details beyond what is in the schema. The mention of language support aligns with the query parameter but does not enhance it. 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 performs full-text search over a specific knowledge base, specifying the domains (AI-native development, agent/harness engineering, dev practice). It distinguishes itself from siblings by explicitly indicating that results are ranked matches with concept ids and directing the user to call read_doc for full text, which differentiates from list_topics.
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 a clear next action (call read_doc with an id), but does not explicitly state when to use this tool versus its siblings (list_topics, read_doc). It implies that search is for finding relevant documents, but lacks explicit 'when to use' or '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.
v0.1.0list_topicsread_docsearch_knowledgeEach tool has a clear and distinct purpose: list_topics for overview, read_doc for reading full content, and search_knowledge for full-text search. There is no overlap or ambiguity.
All tool names follow a consistent verb_noun pattern in snake_case (list_topics, read_doc, search_knowledge), making them predictable and easy to understand.
With only 3 tools, the server is concise and well-scoped for a read-only knowledge base. Each tool serves a necessary function without redundancy or gaps.
The tool set covers the core needs of a knowledge base: browsing topics, reading full documents, and searching. For its stated purpose, there are no obvious missing operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Shared, peer-validated knowledge archive for AI agents — search, contribute, and validate via MCP
Knowledge base MCP for AI agents on iknow.dev. Search, read, and maintain via OAuth.
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/endmoseung/sociableWiki'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
