{"slug": "from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community", "title": "From AI Solutions to Shared Knowledge: Building an MCP for the Community", "summary": "A developer has built Shared Knowledge MCP, an open-source MCP server that converts AI conversation solutions into Markdown articles and submits them as GitHub pull requests for human review before publishing to a documentation site with audio versions. The project aims to recycle solved problems into reusable community knowledge, with the first contributions already merged via real pull requests.", "body_md": "*This is a submission for the [Weekend Challenge: Generosity Edition](https://dev.to/challenges/weekend-2026-09-03)*\n\n**Don't Just Ask AI. Give the Answer Back.**\n\nAI is a real force multiplier for software development. It's also the ideal companion for solving technical problems fast. **But all that knowledge — we keep it to ourselves. Or rather, we lose it.**\n\nThe story always stops there.\n\nQuestion → answer → problem solved — and the conversation sinks into the chat history, gone.\n\nThen someone else hits the exact same wall. Same cycle: question → answer → problem solved — and the conversation sinks into the chat history, gone.\n\nThat's the problem. Not that AI can't solve the same issue twice — it's that a working solution already exists somewhere: someone already investigated, tested, found the fix, and had a conversation detailed enough to explain it properly.\n\nWhy should that knowledge evaporate the moment the session ends? Why keep asking the same question over and over — burning electricity, water, and time that's already been spent — instead of recycling that raw material?\n\nThat's the idea behind **Shared Knowledge MCP**.\n\nShared Knowledge is an MCP server that turns a solution from an AI conversation into a proposed Markdown article, then into a GitHub Pull Request submitted for human review. Once merged, the contribution is published to a documentation site and gets an audio version generated with ElevenLabs.\n\nThe project turns a solved problem into a reusable piece of community knowledge — but only when the user makes the explicit decision to share it.\n\nThe conversation itself stays strictly private. The MCP server extracts only the relevant solution, structures it as a standalone English Markdown article, validates it, and opens a Pull Request on GitHub.\n\nNothing gets published automatically. A human reviews the contribution and decides whether it belongs in the shared knowledge base. Only once the PR is merged does the article land on the public documentation site, which in turn kicks off its audio version.\n\nThe pipeline is deliberately minimal:\n\n**AI conversation → explicit sharing → MCP → Markdown → Pull Request → human review → merge → docs + audio**\n\nThe one boundary that matters is human review. The MCP can structure knowledge and prepare a contribution — it can't decide, on anyone's behalf, what deserves to become public knowledge.\n\nThe public documentation site is live:\n\nIt currently hosts four published articles, each with a generated audio version.\n\nTo prove the system actually works across different clients — no shortcuts, nothing hard-coded — I tested `publish_knowledge` through two very different paths.\n\nThe first contribution published through Shared Knowledge went out as a real Pull Request: [Optional dependency crashes the import chain when the import itself isn't optional](https://github.com/pcescato/shared-knowledge/pull/1).\n\nThat PR walks through the whole flow end to end:\n\n`pyproject.toml` that crashed the import chain);`main`;\nThat first PR is also a concrete act of generosity: someone took the time to turn their fix into a resource every future developer hitting the same wall can reuse.\n\nNext, I used a real AI client — GitHub Copilot Chat in Agent mode, running inside a Codespace.\n\nHere, the assistant spontaneously started by querying the existing base through `search_knowledge` to check for duplicates before deciding to publish: [PR #2](https://github.com/pcescato/shared-knowledge/pull/2).\n\nThat behavior wasn't hard-coded anywhere in the MCP server: the server just provides the tools, and the calling assistant decides how to use them. **Shared Knowledge isn't a closed AI app tied to one model — it's an open MCP interface for sharing knowledge.**\n\nThe full project is open source on GitHub:\n\n**Turn solved problems into shared knowledge.**\n*Don't just get the answer. Give the answer back.*\n\n**Shared Knowledge MCP** is a community-driven knowledge base built around AI-assisted problem solving. It is an [MCP (Model Context Protocol)](https://modelcontextprotocol.io) server that lets any MCP-compatible AI assistant (Claude, ChatGPT/Codex, Cursor, …) **search** a shared knowledge base before solving a problem from scratch, and **publish** a freshly solved problem as a community knowledge article — submitted as a GitHub Pull Request for human review, then published as a static documentation website.\n\nThe core principle:\n\n**The conversation remains private. The knowledge extracted from it can be shared.**\nSharing is always explicit and voluntary — nothing is ever published without the user asking for it.\n\n```\nPrivate conversation\n        ↓\nAI-assisted solution\n        ↓\nUser chooses to share\n        ↓\nCaller structures the article (guidelines prompt)\n        ↓\nGitHub Pull Request\n        ↓\nHuman review\n        ↓\nShared knowledge base\n        ↓\nAvailable\n```\n\n…\nThe repo includes the MCP server, the knowledge articles, the Astro/Starlight static site, the GitHub Actions workflows, the test suite, and the documentation.\n\nBuilding a solo PoC in a weekend forces hard limits.\n\nI could have designed a PostgreSQL database, added vector search with embeddings, built a full authentication system, and shipped an admin dashboard.\n\nI didn't.\n\nFor this MVP:\n\nThe server exposes three deliberately simple tools:\n\n`search_knowledge` — searches the base with field-weighted ranking.`get_knowledge` — fetches a specific article safely (path-traversal protected).`publish_knowledge` — validates the structure and opens a GitHub Pull Request.\nAny stdio-compatible MCP client can connect to the server — Claude Desktop, VS Code with GitHub Copilot Chat in Agent mode, and others. A minimal `.vscode/mcp.json` is enough:\n\n```\n{\n  \"servers\": {\n    \"shared-knowledge\": {\n      \"type\": \"stdio\",\n      \"command\": \"${workspaceFolder}/.venv/bin/python3\",\n      \"args\": [\"${workspaceFolder}/server.py\"],\n      \"env\": {\n        \"GITHUB_TOKEN\": \"${env:GITHUB_TOKEN}\",\n        \"GITHUB_REPO\": \"pcescato/shared-knowledge\",\n        \"KNOWLEDGE_DIR\": \"${workspaceFolder}/knowledge\"\n      }\n    }\n  }\n}\n```\n\nClone the repo, `pip install -e .`, set your own `GITHUB_TOKEN`, point it at your own knowledge repo — and any assistant that speaks MCP can start reading from and contributing to the base, opening Pull Requests under your own GitHub identity.\n\nIn my first implementation, the MCP server called Gemini directly, internally, to turn a conversation summary into a structured article. It worked — but it went against the whole point of MCP: the server was turning into a monolithic app tied to one specific AI vendor.\n\nSo I reworked the architecture mid-build.\n\nThe server now exposes an MCP prompt (`knowledge_article_guidelines`) that lays out the structuring rules — English output, mandatory `## Problem` / `## Solution` sections, a controlled category and tag vocabulary. It's the calling assistant that uses **its own model** to structure the content, while `publish_knowledge` only validates and publishes.\n\nIt doesn't matter whether the client runs on Claude, GPT, Gemini, or a local model.\n\nThat choice had a real cost for the challenge: by taking Gemini out of the critical path, I knowingly gave up eligibility for the **Best Use of Google AI** prize. But I'd rather submit a project whose architecture stays true to the idea of interoperability than force a dependency in just to check a prize-category box.\n\nThere's a nice loop in this project: **it was built using exactly the paradigm it argues for.**\n\nInstead of relying on a single assistant, the repo was developed by having several AI environments collaborate, each in a specific role, under human supervision:\n\nA weekend PoC is a fast reminder that architecture diagrams aren't reality:\n\nAn automated review from Copilot CLI reported a very convincing GitHub authentication bug — code excerpt and line number included. I checked before touching anything: the line, and the code it described, simply didn't exist in the repo. A useful reminder that AI review is genuinely valuable, but it still needs a human to check its homework.\n\nAudio generation kept failing with a deeply misleading `invalid_uid` error. The voice picked from the web interface belonged to the shared *Voice Library*, which isn't reachable through the API on a free account. Once I added the voice to \"My Voices,\" a second issue surfaced: an empty `ELEVENLABS_MODEL_ID` variable in GitHub Actions was silently overriding the code's default value — because `os.environ.get()` only falls back to its default when the key is missing, not when it's set to an empty string.\n\nDuring a local test, I deleted an MP3 file without updating `.audio_manifest.json` to match. On the next CI run, the workflow read the manifest and concluded the audio was already up to date. The code wasn't broken — I had just thrown the system's state out of sync by editing files by hand.\n\nAudio generation through ElevenLabs happens **strictly after human review and merge.** No audio is ever produced for an unreviewed Pull Request.\n\nThat said, listening back to the generated MP3s surfaced an interesting engineering reality: **a format that's perfectly suited for human reading and Git diffs isn't necessarily suited for a text-to-speech engine.** Markdown is built for Git, not for speech.\n\nWhen a TTS engine reads raw Markdown, section headings (`## Problem`, `## Context`) run straight into the following text with no real prosodic break. The result lacks breathing room and narrative structure.\n\nThe audio pipeline will need an intermediate scripting step:\n\n```\nValidated Markdown article\n       ↓\nStructure parser\n       ↓\nNarration script (pauses & transition cues)\n       ↓\nElevenLabs API\n       ↓\nFinal MP3 file\n```\n\nInstead of sending raw Markdown syntax straight to ElevenLabs, the pipeline will turn the editorial structure into an actual narration script. The Markdown article stays the single source of truth — the audio becomes a purpose-built derived format.\n\nThe obvious temptation would be to turn this into a full community platform — voting, comments, vector search, dashboards.\n\nI don't think that's the right priority. The point, first, is to validate the simplicity of the loop itself: **someone solves a problem → chooses to give the answer back → someone else gets to reuse it.**\n\nThe natural next step toward a genuinely usable product is hosting the MCP server remotely over **Streamable HTTP** — no local install, just a URL added to whatever assistant you already use.\n\nBut the loop doesn't need voting, dashboards, or a bigger model to work. It needs someone willing to give the answer back — and someone else willing to trust it enough to read it.\n\nShared Knowledge uses ElevenLabs to make validated technical solutions accessible as audio. Audio generation is decoupled from the MCP server and runs exclusively inside GitHub Actions after a Pull Request is merged — guaranteeing that only reviewed, approved content ever gets synthesized into speech.\n\nNot submitted for Best Use of Google AI: the architectural pivot described above deliberately took Gemini out of the critical path in favor of model-agnostic structuring. That's a trade made on purpose, not an oversight.", "url": "https://wpnews.pro/news/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community", "canonical_source": "https://dev.to/pascal_cescato_692b7a8a20/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community-6bk", "published_at": "2026-09-07 03:34:19+00:00", "updated_at": "2026-09-07 03:56:02.131385+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "ai-agents", "generative-ai"], "entities": ["Shared Knowledge MCP", "GitHub", "ElevenLabs", "GitHub Copilot Chat", "Codespace", "pcescato"], "alternates": {"html": "https://wpnews.pro/news/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community", "markdown": "https://wpnews.pro/news/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community.md", "text": "https://wpnews.pro/news/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community.txt", "jsonld": "https://wpnews.pro/news/from-ai-solutions-to-shared-knowledge-building-an-mcp-for-the-community.jsonld"}}