Feason Context

npx add-mcp 'https://www.feason.com/api/mcp'

✦ Feason

Feason Context · REST API 1.3

Christian context API.

Ready for your model.

Give an AI application inspectable Scripture, historical sources, named theological perspectives, and citations it can verify. Feason retrieves the evidence. Your product decides how to use it.

Get an API keyFollow the five-minute quickstart

Contextualize endpointhttps://www.feason.com/api/context/v1/contextualize

Explore the platform

One context layer.

Every way to use it.

Start with the job your product needs to do. Every path uses the same versioned Christian source corpus, stable citations, tradition attribution, and explicit coverage boundaries.

01

Ground answers

Christian AI grounding

Turn a question into model-ready context drawn from Scripture, creeds, councils, historical theology, and named Christian traditions.

Contextualize `` Search

Explore grounding

02

Test assertions

Theological claim checking

Separate supporting, contradicting, qualifying, contextual, and unclassified evidence without treating silence as disagreement.

Evaluate claim `` Claim proof

Explore claim checking

03

Research deeply

Evidence discovery

Search exact passages or assemble a structured research packet with positions, provenance, historical context, caveats, and confidence.

Search `` Evidence packet

See research operations

04

Show your work

Citation integrity

Verify quotations against an immutable release and expose the corpus version behind every answer your application produces.

Verify citation `` Manifest

See verification operations

05

Prove issuance

Signed proof verification

Authenticate a complete claim graph with Ed25519, a separately published trust key, and an append-only Merkle-log receipt.

Signed envelope `` Transparency receipt

Open proof verifier

Choose your connection

From first request to production.

• REST APIFive-minute guided quickstart
• MCPContext tools for compatible agents
• Agent KitSource helpers for named Gospel routes
• Developer atlasAnonymous MCP and REST call activity
• TypeScriptTyped client and response models
• PythonTyped synchronous client
• OpenAPI 3.1Portable machine-readable contract
• Proof verifierIssuer and transparency verification
• API accessScoped, read-only developer keys

Build with Feason

From a useful idea

to a first request.

Six integration recipes for the tools available today. Open a recipe for its request, workflow, and evidence boundaries. REST requests use a server-side Context key; MCP calls use an authenticated client.

Chat and searchA study companion with citationsAnswer a reader’s question with a bounded evidence block and a source drawer they can inspect.View request and workflow

POST /api/context/v1/contextualize

{
  "query": "How do Christian sources describe hope in suffering?",
  "maxTokens": 2000,
  "maxSources": 12
}

1. Retrieve context before asking your model to answer.
2. Keep citation labels attached to the claims they support.
3. Display coverage gaps and truncation alongside the answer.

Retrieved passages are source material. Keep your model’s explanation separate and leave unsupported questions open.

Build the first request →

Teaching and preparationA source pack for a lessonGive a teacher or group leader a research packet to review before writing a lesson or discussion guide.View request and workflow

POST /api/context/v1/evidence-packet

{
  "question": "What primary sources discuss forgiveness and reconciliation?",
  "limit": 12
}

1. Collect Scripture and historical sources in an evidence packet.
2. Review exact passages, provenance, and historical context.
3. Verify quotations before adding them to a handout.

A research packet supports preparation; it does not supply a finished lesson or establish permission to republish every source.

Explore evidence operations →

Research and educationA comparison that names its sourcesHelp readers explore a topic across explicitly selected traditions without flattening their differences.View request and workflow

POST /api/context/v1/evidence-packet

{
  "question": "How is baptism described by the selected traditions?",
  "traditions": [
    "Catholic",
    "Eastern Orthodox",
    "Baptist"
  ],
  "limit": 20
}

1. Let the reader choose the traditions to investigate.
2. Distinguish attributed positions from sources that only mention the topic.
3. Keep missing traditions visible instead of filling gaps with generated positions.

An individual source does not speak for every member of a tradition. Corpus coverage is not a measure of theological agreement.

Explore the study client source →

Editorial workflowsAn evidence check before publicationTurn a draft assertion into a review queue of supporting, contradicting, and qualifying passages.View request and workflow

POST /api/context/v1/evaluate-claim

{
  "claim": "All Christian traditions describe baptism in the same way.",
  "limitPerStance": 4
}

1. Submit one concrete claim from the draft.
2. Review the curated stance groups and unclassified evidence.
3. Revise the wording or request more research before publication.

This example is an assertion to investigate, not a conclusion. Missing evidence does not prove a claim false; a claim proof records evidence and rules, not theological truth.

Explore claim checking →

Publishing and quality checksA quotation check in your editorCheck a quotation against the exact corpus release used during retrieval before an answer is shared.View request and workflow

POST /api/context/v1/verify-citation

{
  "passageId": "<passageId from retrieval>",
  "quote": "<exact quotation to check>",
  "corpusVersion": "<corpusVersion from retrieval>"
}

1. Replace all three placeholders with values from your retrieval result and draft.
2. Inspect verified, matchKind, and any reason in the verification response.
3. Hold mismatches for review and preserve the release identifier with the citation.

A matching quotation establishes text agreement with a snapshot. It does not establish that the surrounding argument is sound.

Follow the citation workflow →

Agents and reading appsA reader focused on one GospelRetrieve a named Gospel passage and its surrounding context before offering a study explanation.View request and workflow

MCP · get_scripture_context

{
  "reference": "Matthew 5:1-12",
  "contextWindow": 2,
  "limit": 12
}

1. Connect an MCP client with the context:read scope.
2. Call get_scripture_context with the reader’s explicit reference.
3. Keep the requested passage, related evidence, and generated explanation distinct.

Check that retrieval returned the requested passage. Ask for a choice when multiple Gospels are named; never silently substitute another book.

Explore the Agent Kit source →

Decision guides

Choose the evidence layer before the model.

Compare product categories by source identity, provenance, coverage, verification, and the work your team still owns.

Feason Context vs. generic theology RAG

Compare corpus ownership, provenance, tradition coverage, citation verification, and operational responsibility.

Read the guide →

APIs for grounding Christian AI

Choose among Scripture text, source search, theological evidence, and current-web APIs by evidence contract.

Read the guide →

Bible API vs. theological evidence API

Separate canonical reading needs from historical, doctrinal, and tradition-aware research needs.

Read the guide →

Verify theological AI citations

Resolve, compare, contextualize, and audit quotations before an AI-generated answer is published.

Read the guide →

Quickstart

One call.

Grounded context.

Send the user’s question with a prompt budget. The response’s context field can be placed directly before the question in your model input. Citation metadata remains separate and inspectable.

• The key is scoped to read-only canonical context.
• The response never claims that missing coverage means a tradition has no teaching.
• Disputed positions stay attributed to their source or tradition.

RequestPOST /contextualize

curl https://www.feason.com/api/context/v1/contextualize \
  -H "Authorization: Bearer $FEASON_CONTEXT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "How did early Christians speak about grace?",
    "traditions": ["Catholic", "Eastern Orthodox", "Reformed"],
    "maxTokens": 2000,
    "maxSources": 12
  }'

Responseapplication/json

{
  "corpusVersion": "theology-v7.0.0",
  "context": "# Feason Context\n...",
  "citations": [{ "label": "E1", "passageId": "..." }],
  "coverage": {
    "representedTraditions": ["Catholic", "Eastern Orthodox"],
    "missingTraditions": ["Reformed"]
  },
  "usage": { "estimatedTokens": 1842, "truncated": false }
}

Claim checking

Test a claim.

Keep the nuance.

Feason matches the wording to a curated claim definition, retrieves relevant passages, and groups only human-annotated stances. Your interface can show the evidence behind each category instead of presenting an unexplained verdict.

• Supporting and contradicting passages remain inspectable.
• Qualifying evidence stays distinct from opposition.
• Silence, missing retrieval, and unclassified passages never become negative proof.

RequestPOST /evaluate-claim

curl https://www.feason.com/api/context/v1/evaluate-claim \
  -H "Authorization: Bearer $FEASON_CONTEXT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "claim": "Children of believers may be baptized.",
    "limitPerStance": 5
  }'

Response shapeapplication/json

{
  "normalizedClaim": "infants-may-be-baptized",
  "supportingEvidence": [],
  "contradictingEvidence": [{ "passageId": "..." }],
  "qualifyingEvidence": [{ "passageId": "..." }],
  "contextualEvidence": [],
  "unclassifiedEvidence": [],
  "confidence": 0.92,
  "negativeEvidencePolicy": "Only explicitly opposing annotations..."
}

REST surface

Seven operations with clear jobs.

All operations use bearer authentication, concrete JSON contracts, per-client limits, and the same immutable Context corpus behind Feason’s MCP server.

POST/api/context/v1/contextualize

Build model-ready context

One call returns a token-budgeted evidence block, stable citation labels, and explicit tradition coverage.

POST/api/context/v1/evaluate-claim

Check a theological claim

Group retrieved passages by curated stance, with explicit caveats and no false negative inference from silence.

POST/api/context/v1/claim-proof

Build a claim proof

Commit exact evidence, disclosed rules, validation checks, and a bounded result to an unsigned SHA-256 Merkle root.

POST/api/context/v1/search

Search exact passages

Run lexical, semantic, or hybrid retrieval over the versioned corpus with source and tradition filters.

POST/api/context/v1/evidence-packet

Assemble research evidence

Retrieve Scripture, primary sources, historical context, positions, provenance, caveats, and confidence.

POST/api/context/v1/verify-citation

Verify a quotation

Check a passage or exact quote against an immutable corpus release snapshot.

GET/api/context/v1/manifest

Inspect the active release

Read the active corpus version, source counts, relationships, claims, and verification distribution.

OpenAPI 3.1 contractTypeScript clientPython client

Developer access

Create a scoped key.

Self-service keys can read only the shared canonical corpus. Access to a member’s private study context uses OAuth and explicit consent instead.

Checking your Feason session…

Product boundary

Evidence in. Verdicts out.

Feason improves what a model can inspect without claiming that retrieval itself settles interpretation.

Source-first

Every included passage carries a stable ID, reference, provenance URL, license, and verification status.

Tradition-aware

Differences are named and sourced. Missing corpus coverage remains visible instead of becoming synthetic consensus.

Prompt-bounded

The context block respects the requested budget and reports when evidence was omitted or shortened.

Questions

Christian Context API FAQ.

What developers need to know before grounding an AI product in Christian sources.

What is a Christian context API?

A Christian context API retrieves relevant Scripture and theological sources for an application. Feason returns exact passages, provenance, citations, named tradition coverage, and explicit caveats so AI-generated answers can be inspected.

Can Feason Context be used with any AI model?

Yes. The REST API returns provider-neutral JSON and prompt-ready Markdown. Applications can use the context with OpenAI, Anthropic, Google, open-source, or other language models.

Does the API favor one Christian denomination?

No. Feason is non-denominational and source-grounded. Disputed views are attributed to their sources and traditions, while missing corpus coverage is reported instead of treated as absence of teaching.

How do developers authenticate?

Signed-in Feason members can create scoped, read-only developer keys. Each key expires after 90 days, can be revoked, and cannot access a member’s private study context.