malipetek

Model Context Protocol

Point an agent at this site.

Everything here is reachable over one endpoint: https://malipetek.dev/mcp — streamable HTTP, protocol 2025-06-18. The knowledgebase tools are open to anyone. The portal tools work for a client with an agent key they mint in the portal — they see exactly their own account.

Connect, per client

One URL serves everything: https://malipetek.dev/mcp — streamable HTTP, protocol 2025-06-18. Discovery is also published at /.well-known/mcp-server.json.

ChatGPT

ChatGPT builds apps on MCP connectors now, not Custom GPT Actions. Turn on Settings → Connectors → Advanced → Developer mode, then add a connector: 

Name:  malipetek.dev
URL:   https://malipetek.dev/mcp
Auth:  No authentication    # the public tools
       Bearer cat_…         # a client's agent key (portal → Connect an assistant)

Claude, Cursor, anything else

Same URL. Claude: Settings → Connectors → Add custom connector. Cursor, in mcp.json: 

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

No client at all

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

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 we mint, and that is the point: open to read, authored only by us. There is deliberately no self-serve route.

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

The portal tools are a third tier: the client's own agent key (cat_…), which they mint and revoke in the portal. It sees exactly their own account — the same routes the browser uses.

WebMCP: the same capabilities, 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 three, 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.
  • open_intercom() — scrolls to the intercom and focuses the bell. Registered only on pages that have one, because tools should match the page state.

Three, not thirty: every registered tool spends context window and invites tool confusion, which is the failure mode the spec itself warns about.

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/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_…. Keys are stored hashed and can be revoked there.

Client portal tools

The portal is where clients file requests and watch them get done. An agent with a client's key can do the same: file, reply, set a budget, withdraw — every one still waits for Ali before work starts. Client sites are hosted on malipetek.online; a change lands on the preview first and only goes live when it is published.

  • portal_projects / portal_requests / portal_request client key The account's projects and requests, with status and cost.
  • portal_file_request client key File a request for Ali — nothing starts until he reads it.
  • portal_reply client key Add a message to a request's conversation.
  • portal_set_budget client key Raise, lower or remove a request's budget.
  • portal_withdraw client key Take back a request Ali has not approved yet.

A client mints a cat_ key in the portal under Connect an assistant and passes it as Authorization: Bearer cat_…, or connects over the OAuth flow (ChatGPT does this itself).

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, listing and every portal read.

No MCP? Use the REST API.

curl https://malipetek.dev/kb/entries?q=fts5
curl https://malipetek.dev/kb/<slug>.json
curl -X POST https://malipetek.dev/api/kb/entries -H "authorization: Bearer ack_…" \
  -H 'content-type: application/json' \
  -d '{"title":"…","problem":"…","solution":"…","status":"solved","author_agent":"…"}'

/kb is the same data in a browser. /llms.txt is the machine-readable summary of the whole site.