MCP endpoint

The KF server exposes its knowledge graph over the Model Context Protocol at the /mcp endpoint. Any MCP-compatible LLM client — Claude Desktop, VS Code Copilot, or a custom agent — can connect and gain full read access to the KF database: search it, walk the relations between items, and pull complete failure analyses and compliance checklists, all in the client's own words.

Connecting

The endpoint uses the MCP Streamable HTTP transport. All tools are synchronous and read-only.

https://kf.example.com/mcp

Add it to your MCP client configuration. For Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "kf": {
      "url": "https://kf.example.com/mcp",
      "headers": { "Authorization": "Bearer f0e1d2…" }
    }
  }
}

The /mcp endpoint is never served anonymously — every connection needs a personal access token (sent as Authorization: Bearer …) or an active session. A token carries exactly the access of the user who created it: the MCP client sees precisely the items that user would see in the browser, no more. See authentication & access to create a token.

The data model in brief

KF stores items. Every item has a stable id, a title, a class (m module, i container/item, e event, a action, t type), an optional code (SKU / x0), space-separated tags, and a parent. Items are joined by typed edges:

EdgeMeaning
causality — this item causes that event
containment — component of
type / instance — this item is an instance of a type
*action — a to-do linked to an item or event
outcome — an expected result
precedence

Actions and outcomes carry a status tag: done, not_applicable (na), missing (required by a type but not yet present), or absent (pending). This mirrors the REST API model — the MCP tools are the read side of the same store, presented for an LLM.

Tools

The server publishes the following read-only tools. Every tool that acts on a single item takes an id parameter.

ToolPurpose
searchfull-text (BM25) search across all items
get_itemfetch one item's core fields (and its Markdown doc body)
get_item_pathbreadcrumb path — walks the parent chain
get_componentsdirect sub-components ( downward)
get_eventsevents this item causes ( downward)
get_events_upevents that caused this item ( upward)
get_actionsto-do actions linked to an item (*)
get_outcomesexpected outcomes linked to an item ()
get_typestypes this item learns from ( upward)
get_instancesall instances of a type item ( downward)
get_checklistfull compliance checklist, merging requirements inherited from types
get_checklist_summaryaggregated done / na / missing / pending counts per item and type origin
get_inverted_checklistlessons-learned view — actions on instances not yet promoted to the type
get_failure_analysisFMEA-style tree: item + components + types, each with its events and actions
get_failure_treefault tree as indented text — top event down to root causes
get_by_tagall items carrying a given tag
get_by_codelook up an item by its code (SKU / x0)

search runs a full-text query in BM25 rank order. The query accepts FTS5 syntax: plain keywords, "exact phrase", prefix*, the boolean operators AND / OR / NOT, and field qualifiers such as title:pump. Each hit is a compact reference:

{ "id": "abc123", "title": "Pump failure", "type": "e", "link": "/item/abc123" }

Compliance and failure-analysis tools

These are the tools that turn KF into more than a search box. get_checklist returns every required action and outcome for an item — including those inherited from its types but not yet present on the instance, which appear as missing:

{
  "item_id": "abc123", "item": "Pump P-101",
  "event": "Seal failure", "action": "Replace seal", "status": "done"
}

get_checklist_summary aggregates the same data into counts per item and type origin (done, na, missing, pending, total) — the shape you want for a dashboard. get_inverted_checklist flips the question: it anchors on the instances of a type and flags actions that exist on an instance but not on the type — lessons-learned candidates that should be promoted so every future instance inherits them.

get_failure_analysis returns the full FMEA tree — the item with all its components and types (flat, with an indent depth), each carrying its event tree and the actions on every event:

[
  {
    "id": "abc123", "title": "Pump P-101", "class": "i", "indent": 0,
    "events": [
      { "id": "ev-01", "title": "Seal failure", "indent": 1,
        "actions": [
          { "id": "ac-01", "title": "Inspect seal", "status": "done" },
          { "id": "ac-02", "title": "Replace seal",  "status": "pending" }
        ] }
    ]
  }
]

Typical workflows

The tools are designed to be composed by the LLM in response to a plain-language request. A few common chains:

Compliance report for an itemsearch("hydraulic pump")get_item(id) to confirm → get_item_path(id) for context → get_checklist(id) for the row-by-row status → get_checklist_summary(id) for the executive counts, then compose a Markdown report grouped by status.

*"Prepare a compliance report for the hydraulic system. Show which required

actions are complete, pending, not applicable, and missing. Include a summary

table and a detailed row-by-row list."*

Failure-analysis (FMEA) reportsearch("pump")get_failure_analysis(id) for the event/action tree → get_failure_tree(event_id) for the causal chain of a specific event, then compose an FMEA table.

*"Generate a complete FMEA table for item abc123. For each failure mode list the

associated corrective actions and their current status. Format it as Markdown."*

Finding lessons learnedsearch("pump type")get_inverted_checklist(type_id)get_instances(type_id), then summarise which lessons should be promoted to the type.

*"Which actions exist on individual pump instances but are not yet part of the

standard 'Pump' type? Present them as proposed additions to the type."*

Exploring the graph — the navigation tools answer questions directly: "What components does the cooling system contain?" (get_components), "What can this seal assembly trigger?" (get_events), "What caused the loss of pressure?" (get_events_up), "Walk the causal chain from plant trip back to root causes." (repeated get_events_up).

Notes

  • The endpoint is read-only. To create or update items from a program, use the writable REST API.
  • Access is always scoped to the token's user through the KF access-control labels — an MCP client cannot see items its user cannot.