malipeteklab

Model Context Protocol

Point an agent at the knowledgebase.

https://lab.malipetek.dev/mcp is the knowledgebase server: streamable HTTP, protocol 2025-06-18. Reading is open to everyone. Writing needs an ack_ key that Ali mints. This endpoint has no portal tools; the client portal has its own at malipetek.dev/mcp.

Connect

In Claude: Settings → Connectors → Add custom connector. In ChatGPT: turn on Settings → Connectors → Advanced → Developer mode, then add a connector. In Cursor, mcp.json: 

{ "mcpServers": { "malipetek-kb": { "url": "https://lab.malipetek.dev/mcp" } } }

No client at all:

curl -s https://lab.malipetek.dev/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

REST works too, without MCP: 

curl https://lab.malipetek.dev/kb/entries?q=fts5
curl https://lab.malipetek.dev/kb/<slug>.json

Onboarding: what an agent needs, and what it does not

Reading needs nothing. search_knowledge, get_knowledge, list_knowledge, every kb://entry/… resource and the whole REST API are open. No key, no sign-up, no handshake.

Writing needs a key Ali mints. That is the point: open to read, authored only by us. There is deliberately no self-serve route.

  1. Ali signs in at malipetek.dev/portal and opens /kb/new.
  2. He mints a key named after the agent that will hold it (claude-code, cursor…).
  3. The agent sends it as Authorization: Bearer ack_…. It is stored only as a SHA-256 hash and shown once.
  4. Every use updates last_used_at. Revoking is one click, so a leaked key is visible and short-lived.

Knowledgebase tools

  • search_knowledge public Full-text search over every entry. Prefix matching, so `migra` finds `migration`.
  • get_knowledge public One entry in full (problem and solution markdown) by id or slug.
  • list_knowledge public Newest entries first, without bodies.
  • create_knowledge ack_ key Record a problem and solution pair from a session.
  • update_knowledge ack_ key Patch an entry this key authored.

Mint an ack_ key at /kb/new (owner only) and pass it as Authorization: Bearer ack_….

Resources and prompts

Tools are for calling; resources are for attaching. Every entry is also a resource at kb://entry/<slug> (text/markdown), so a client can pin the relevant entry into context instead of asking the model to fetch it. resources/list pages at 50 with a cursor, and kb://entry/{slug} is advertised as a template.

One prompt, record_learning, takes a topic and an outcome and returns the instructions for turning the session that just ended into an entry: search first so it updates rather than duplicates, and pick the status honestly.

Every tool carries MCP annotations, so a connector can tell reading from writing before it asks. readOnlyHint is true for search and listing.

WebMCP: the same knowledge, inside the page

A backend MCP server is something the agent's platform reaches. WebMCP (document.modelContext) is the other direction: the page registers tools that reuse its own code and keep the visible UI in sync with what the agent just did.

This site registers two, feature-detected. A browser without the API loads the module and does nothing at all.

  • search_knowledge(query, status?) returns entries, and updates the visible results when the visitor is on /kb.
  • open_knowledge_entry(slug) opens the entry in the visitor's own browser.

The contracting site has its own open_intercom tool, registered only on pages that have an intercom. Every registered tool spends context window and invites tool confusion, so the lists stay short.

What this is not

This endpoint has no client portal tools. If you are a client of Ali's and want your assistant to file or follow a request, use malipetek.dev/agents instead. The two servers are separate on purpose: a summary of one should not describe the other.