Your home in the engine.

Surfaces for agents

Each surface answers a different kind of question. Read the read surfaces (atlas, almanac) before deciding to verify from scratch — there's a good chance the engine has already worked the answer through.

MCP tool inventory

111 MCP tools total: 69 verifiers (one per deterministic domain check), plus pipeline tools (validate / seal / attest / walk through), read & synthesize surfaces (atlas, almanac, run_polymathic, propose_almanac_entry), and the 12 card-library tools added 2026-05-19 (cards_walk, shepherd_interview, atlas_paths, card_get, card_notes, daily_card, etc.). Every tool is reachable over stdio MCP, HTTP MCP, and SSE MCP — same wire format, same behavior.

Card library tools — new 2026-05-19

Engine + verification tools

Beyond MCP — REST endpoints worth knowing

The engine exposes more than the MCP tool surface. These REST endpoints make the full substrate addressable from any HTTP client:

Card library REST endpoints — new 2026-05-19

All public read endpoints are unauthenticated. Write endpoints (misalignment review, receipt minting, card promotion, community note flagging) require the operator API key. Full OpenAPI: /openapi.json.

Quick integration

Five doors in. /connect has the full step-by-step with copy-paste configs and live test buttons. The summary:

1 · MCP over HTTP — hosted, no install

The fastest path. https://narrowhighway.com/mcp is a remote MCP endpoint that any MCP-compliant client (Claude Desktop, Cursor, custom) can connect to without installing anything.

{
  "mcpServers": {
    "concordance": { "url": "https://narrowhighway.com/mcp" }
  }
}

Also available over SSE: https://narrowhighway.com/mcp/sse. All 111 tools become available immediately.

2 · MCP over stdio — for offline / air-gapped use

Install once, run locally. No outbound calls.

pip install concordance-engine
# then in your MCP client config:
{
  "mcpServers": {
    "concordance": { "command": "concordance-mcp" }
  }
}

Claude Code: claude mcp add concordance -- concordance-mcp

3 · REST — any language, no install

Base URL: https://narrowhighway.com · No API key required for read endpoints. 120+ routes total (every MCP tool plus journal, ledger, audit-chain, grid, polymathic, the full card library).

# Walk the card library — Shepherd pulls top-7 cards for a question
curl -X POST https://narrowhighway.com/cards/walk \
  -H "Content-Type: application/json" \
  -d '{"query": "What is the chief end of man?", "k": 7}'

# Pre-flight interview before a broad query (shapes the question first)
curl -X POST https://narrowhighway.com/shepherd/interview \
  -H "Content-Type: application/json" \
  -d '{"query": "baptism", "asked_by": "agent_X"}'
# Returns {state: "needs_followup", shepherd_says: "Who is this for?",
#          interview_id: "..."}; pass the user's reply back with the same
# interview_id until state="ready_to_walk", then call /cards/walk.

# Today's card (deterministic worldwide)
curl https://narrowhighway.com/daily-card

# Verify a chemistry claim
curl -X POST https://narrowhighway.com/verify/chemistry \
  -H "Content-Type: application/json" \
  -d '{"equation": "H2 + O2 -> H2O"}'

# Classify and trace a path
curl -X POST https://narrowhighway.com/path \
  -H "Content-Type: application/json" \
  -d '{"text": "I feel called to plant a church but I do not know when."}'

How an agent should walk the cards — canonical pattern

The card library was built for two audiences — humans at /walks.html and agents over MCP. The canonical agent pattern:

# 1. If the user's question is broad, run the interview first.
result = shepherd_interview(query="baptism")
while result["state"] == "needs_followup":
    user_reply = ask_the_user(result["shepherd_says"])
    result = shepherd_interview(
        query=user_reply,
        interview_id=result["interview_id"],
    )

# 2. Walk the cards with the shaped question.
walk = cards_walk(query=result["shaped_query"], k=7)

# 3. Read the cards back to the user — cite each card by its source.
#    Never present a card's content as your own.
for step in walk["steps"]:
    card = card_get(step["card_id"])
    say_to_user(
        f"{card['title']}: {card['body']}\n"
        f"(Source: {card['source']['label']} · {card['source']['ref']})"
    )

# 4. Walk the connections between cards — that's the lesson.
for step in walk["steps"]:
    conns = card_connections(step["card_id"])
    for outgoing in conns["outgoing"]:
        # follow proof texts, parallels, illuminates relationships

Cards carry their own authority (scripture, catechism, creed, father, matt). The agent's job is to walk them with the user — never to synthesize when a card already answers, never to paraphrase scripture or catechism. Quote verbatim with the reference.

4 · OpenAPI — auto-import for OpenAI / LangChain / Custom GPTs

The full spec is at /openapi.json. Custom GPTs accept it directly via "Actions → Import from URL." Live Swagger UI: /docs. ReDoc: /redoc.

Full integration guide →

POST /path — the standalone model

Send text. Receive a Scripture-anchored path. No packet format, no gates required — just what is being carried.

Pipeline: classifier → Scripture retrieval → personal context overlay → path composer.

Request

{
  "text": "what are you carrying right now?",
  "gate_verdicts": {}   // optional — override from an external gate engine
}

Response — PathResult

{
  "question_type":  "WISDOM | DOCTRINE | DECISION | RELATIONAL | RESOURCE | TIMING | FORMATION | CRISIS | HISTORICAL",
  "confidence":     0.0,
  "gate_verdicts":  {},
  "scripture_anchor": {
    "primary":    "Proverbs 2:6",
    "text":       "For the LORD gives wisdom. Out of his mouth comes knowledge and understanding.",
    "supporting": ["James 1:5", "Proverbs 3:5-6"]
  },
  "personal_context": {
    "relevant_packets":  0,
    "pattern":           null,
    "recurring_anchors": [],
    "precedent":         null,
    "first_seen_at":     0.0,
    "unresolved":        false
  },
  "path":                "≤3 sentences — not an answer, a direction",
  "next_step":           "one thing — singular, never a list",
  "timing":              "WAIT | HOLD | MOVE | UNCLEAR",
  "life_safety":         false,
  "needs_clarification": false,
  "clarification_prompt": null
}

Nine question types and their primary anchors

Verification surface

Four gates, fixed order. Halt at the first failure. No looping back, no consensus override.

Two distinct layers: The computational verifiers (chemistry, physics, mathematics, statistics, scripture, and 31 others) run against external standards — deterministic, operator-independent, falsifiable. The policy gates (RED, FLOOR, BROTHERS, GOD) are operator-defined governance rules. Both are strong claims; they are not the same kind of claim. The verifiers produce CONFIRMED or MISMATCH against a fixed external standard. The gates produce PASS, REJECT, or QUARANTINE against rules the operator configured. Know which layer you are reading.

Verification endpoints

Minimal governance packet

{
  "packet": {
    "title":      "Short label for this decision",
    "decision":   "The specific action being taken",
    "rationale":  ["Reason 1", "Reason 2"],
    "scope":      ["Who or what is affected"],
    "authority":  "The role or body making this decision",
    "witnesses": [
      {"name": "Name", "role": "Role", "timestamp_epoch": 1234567890}
    ],
    "scripture_refs": ["Proverbs 11:14"],
    "submission_timestamp_epoch": 1234567890
  }
}

Journal surface

The capture layer. What enters here has not yet survived the gates. Seeds are what the keeping notices; precedents are what survive and get sealed.

Computational verifiers

Deterministic. Run locally. No network calls. Available as MCP tools and as verifier endpoints (POST /verify/{domain}).

Full verifier reference →

Scripture layer — Layer 0

The root authority. Domain canons are calibrations downstream of it. The /path endpoint draws from this layer for every submission.

Sources: Westminster Leningrad Codex (Hebrew morphhb), MorphGNT (Greek NT), Strong's lexicon (Hebrew + Greek), World English Bible (WEB, public domain). 300,807 Hebrew + 59,845 Greek word occurrences, fully cross-referenced.

What is expected of you

Service endpoints

Polymathic surface — Path C

A single situation can span chemistry, labor law, construction, finance, and governance simultaneously. The polymathic agent — the orchestrator — fires all applicable verifiers at once and synthesizes a composite verdict.

Architecture: verifiers, dispatchers, coordinator

• Verifiers — the 48 verify_* functions. One domain, deterministic, offline.
• Dispatchers — rule-based + oracle-based classifiers that route a natural-language claim to the right verifier.
• Coordinator — the polymathic agent. Runs all verifiers and synthesizes the collective result.

Three-phase pipeline

Quarantine

Claims that decompose cleanly but cannot be classified to any domain are quarantined: not wrong, not confirmed, just unverifiable with the information at hand. The Keeper component triages quarantine without any oracle calls — pure rule-based recovery and keyword proximity scoring, suitable for offline / LoRa deployment. The composite verdict is QUARANTINE when unresolved claims remain alongside confirmed domains.

POST /polymathic

Request body:

{
  "situation": "I worked 55 h/wk as a misclassified contractor for three years...",
  "oracle_model": "claude-haiku-4-5-20251001",   // optional
  "max_domains": 10,                              // optional, default 10
  "split_threshold": 5,                           // optional, default 5
  "stop_on_discordant": false,                    // optional
  "store": true                                   // optional — store result in CAS
}

Response — PolymathicRecord:

{
  "schema_version":    "1.0",
  "situation":         "...",
  "composite_verdict": "CONCORDANT | DISCORDANT | MIXED | QUARANTINE | OUT_OF_SCOPE | ERROR",
  "atomic_claims":     ["claim 1", "claim 2", ...],
  "quarantined_claims": [],
  "keeper_manifest":   null,
  "domain_results": [
    {
      "domain":       "labor",
      "verdict":      "CONFIRMED | MISMATCH | NOT_APPLICABLE | ERROR",
      "detail":       "...",
      "spec":         {...},
      "axis_dims":    ["time_sequence", "authority_trust"],
      "source_claim": "I worked 55 hours per week..."
    }
  ],
  "axis_overlaps": [
    {"dimension": "authority_trust", "domains": ["governance", "labor", "finance"]}
  ],
  "content_hash": "sha256..."
}

Try the polymathic agent live →