fabian s. klinke

public knowledge.

read-only MCP server

The website, as a source.

This website contains notes, essays, research references, music, software, recipes and books. The public knowledge MCP makes the textual parts searchable from an AI client. It is a read-only interface to material that is already public on klinke.studio.

You can ask a broad question, open the relevant source, read it in sections or look for related documents. Every result keeps its title, URL and provenance attached so a study note does not quietly turn into a current belief and a cited paper does not become something I wrote.

Getting started.

Add the following URL as a remote HTTP MCP server in a compatible client. Most clients ask for a name and a server URL. The example JSON shows the common shape; the exact settings screen or configuration syntax depends on the client.

https://www.klinke.studio/api/mcp
{
  "mcpServers": {
    "klinke-studio": {
      "url": "https://www.klinke.studio/api/mcp"
    }
  }
}

Once connected, try questions such as:

  • What does Fabian mean by truth to material?
  • Find notes about sound, emotion and physiological arousal.
  • Which writing discusses audio software or mixing?
  • Find a recipe that uses mushrooms and lemon.
  • What sources in the bibliography discuss music recommendation?

What the server can do.

Search public knowledge.

search_public_knowledge accepts a natural-language query, an optional content-type filter and a result limit. It returns ranked excerpts with stable document IDs, source URLs, matching sections and retrieval diagnostics.

Read a source.

get_public_document reads a document by its stable ID. Long documents use character offsets, so a client can continue reading without silently losing the end. get_public_document_chunks returns the same source as heading-aware sections.

Move sideways.

get_related_public_documents finds nearby material. For notes, these relationships come from the same semantic index used by search. They are not a second embedding database.

Inspect the index.

get_public_knowledge_index_status reports the current index version, embedding model, generation time and source coverage. It is useful when a client needs to distinguish an empty result from an unavailable index.

What is indexed.

The index includes text whose meaning survives without its visual layout:

  • published notes and study notes;
  • published writing and clearly marked drafts;
  • music, software and product pages;
  • recipes, expressed as ingredients, preparation and instructions;
  • books, wishlist records and bibliography metadata; and
  • page-aware segments from bibliography PDFs.

The design archive, photography, CV and general static pages are excluded. Their useful information is mainly visual, biographical or already represented by a more precise source. Indexing everything merely because it has text made the results noisier.

How retrieval works.

One index, several signals.

Source documents are split along Markdown headings and PDF pages. Large sections are divided into bounded chunks with a small overlap, while the heading path and source location remain attached. Each chunk then enters one versioned public-knowledge index. The same index supplies MCP search and the related-note map shown elsewhere on the website.

Lexical retrieval.

A BM25-style ranker handles exact words, rare terms, names and technical phrases. Titles, headings and metadata receive stronger field weights than ordinary body text. Stopwords are removed in English and German, and distinctive title terms allow limited one-character typo tolerance. Query-term coverage prevents a document that matches one generic word from outranking a document that matches the whole question.

Semantic retrieval.

Every chunk has a compact 512-dimensional embedding made withtext-embedding-3-large. This retrieves conceptually related passages when the wording changes, including useful English–German matches. The stored vectors are normalized and quantized to reduce the size of the public artifact.

Fusion and parent ranking.

Lexical, indexed-PDF and semantic candidates are combined with weighted reciprocal rank fusion. Strong natural-language semantic matches get more weight than isolated PDF keywords. Chunk results then collapse to their parent document, with the best matching section used as the excerpt. The result is still explainable: each item can report where it ranked in each retrieval lane.

Graceful fallback.

Semantic query embeddings require the server-side OpenAI credential. If that service is unavailable, exact lexical and indexed-PDF retrieval continue to work. A missing semantic service makes the search less flexible; it does not make the public archive disappear.

PDFs without a public text dump.

Bibliography PDFs contain some of the most useful research in the collection, but a searchable research passage is different from republishing a paper. The public index therefore stores term postings, vectors, page numbers and attribution, not the extracted sentences themselves.

When a PDF page wins a query, the server fetches that page from the existing source, extracts its text and returns a short passage around the matching terms. The response includes the bibliography record and page location. The MCP does not provide a tool for reconstructing complete PDF text from these excerpts.

Provenance and limits.

Results distinguish authored work, study notes, third-party references and collection records. Drafts remain drafts. A book in my library is evidence that it is in the library, not that I agree with it. A study note records what I was learning when I wrote it, not a permanent position.

The server searches only public website material. It has no access to private Personal World memory, files, messages, accounts or unpublished material outside the drafts intentionally included in this website index. Retrieval can still be wrong. Keep the linked source visible and read it before making a consequential claim.