latentWhat a client gets
The public MCP interface exposes search_articles, list_articles, and get_article. It gives an assistant a way to discover and retrieve published articles without scraping the visual page. Publication and administration are outside this tool catalog.
The recorded browser client initializes the endpoint, discovers tools, lists articles, searches for MCP, retrieves a result, and requests a deliberately missing article. The saved exchange contains transport requests and responses. It demonstrates protocol behavior; it is separate from the article's saved retrieval-backed model answers.
Architecture and retrieval choices
MCP client → JSON-RPC endpoint → validated tool arguments
→ search_articles → BM25 + pgvector → reciprocal-rank fusion
→ list_articles → published article query
→ get_article → published Markdown + structured metadata
The site reuses its search and Markdown services. Hybrid search combines keyword and semantic rankings; a search result identifies candidates for reading. get_article returns the full body in text content and metadata separately, avoiding a duplicate body in structured content.
A caller should search for a topic, use returned slugs, retrieve relevant articles, and attach its answer to the retrieved material. Successful transport does not prove the final answer is supported. That requires inspecting the model's citations and claims against the returned text.
Tool contracts and error layers
| Tool | Main inputs | Review target |
|---|---|---|
| search_articles | query, limit, lang | Published matches and usable slugs |
| list_articles | optional tag, limit | Publication filtering and ordering |
| get_article | slug, lang | Full Markdown and missing-slug behavior |
The saved discovery response bounds a search query to 1 through 500 characters and its limit to 1 through 20. Listing allows up to 50. Language-aware tools accept English and Spanish. Those are the captured contracts; clients should discover the running server's schemas when connecting.
Invalid tool input and a missing article return a tool result with isError: true, allowing a model to revise its request. An unknown JSON-RPC method is a protocol-layer error. A client that treats both as an empty successful result hides information needed for recovery.
A useful negative test
The small protocol capture includes initialization, tool discovery, and get_article for portfolio-nonexistent-evidence-check. The returned tool result explicitly says no published article exists with that slug and sets isError: true.
That capture makes no model or embedding call. The later narrated session includes search and retrieval. Keep the two captures separate when discussing what was exercised. Likewise, requesting an unsupported protocol version tests negotiation rather than article quality. The inspected implementation lists compatibility with 2024-11-05, 2025-03-26, and 2025-06-18; this is not a promise about later revisions.
Reproduction and publication isolation
The public companion ZIP supplies a runnable example with synthetic articles, local keyword search, and protocol tests. It reproduces the interface pattern, not production BM25 and pgvector indexes. Its source manifest records the companion and inspected site files.
Begin with initialization and discovery. Call every tool with valid and invalid arguments, request a missing slug, and check that unpublished content cannot be retrieved or searched. Only then add an assistant and evaluate whether it chooses appropriate tools and supports its answer.
The technical article records a test-isolation failure: fixture articles reached the real content directory and were published by deployment and seeding. The test harness now uses a disposable working directory. Database mocks alone did not isolate filesystem side effects. For a reproduction, keep fixtures outside any directory that publishing or backup restoration can ingest.
The report preserves a captured compatibility and retrieval contract. It does not introduce new load measurements, claim compatibility with every client, or treat a successful demo as proof of draft exclusion across all paths.