Ports

MCP quickstart

eli.ai isn't only an API you call — it's a Model Context Protocol server any agent can connect to. Point Claude, an IDE agent, or any MCP client at https://your-host/api/mcp with your workspace key and the knowledge graph and governed data layer become native tools, under the same RLS and provenance as everything else. One command gets you there.

Prerequisites

A workspace key (eli_sk_…). The MCP tools are read-only; a key with kb:read and data:read covers the catalog. See Getting started.
An MCP client — Claude Code, Claude Desktop, or any client that speaks streamable HTTP.

Connect in one line

Claude Code:

claude mcp addbash

claude mcp add --transport http eli https://your-host/api/mcp \
  --header "Authorization: Bearer $ELI_KEY"

Or drop it into a client config file — Claude Desktop, IDEs, and most other clients accept this shape:

.mcp.jsonjson

{
  "mcpServers": {
    "eli": {
      "type": "http",
      "url": "https://your-host/api/mcp",
      "headers": {
        "Authorization": "Bearer eli_sk_..."
      }
    }
  }
}

The key picks the workspace

Scope comes entirely from the key — there is no workspace argument in any tool input, and no way to name another tenant. Every tool call runs under that workspace's row-level security. The server is stateless streamable HTTP: each request is self-contained, safe behind any load balancer.

The tool catalog

Six read-only tools, from fine-grained retrieval to the whole pipeline in one call:

kb_search — hybrid lexical + semantic search; scored chunks with document metadata.
kb_graph_query — expand the graph around seed entities (depth 1–3, type filters); nodes and typed edges.
kb_entity_lookup — resolve entities by name (exact / alias / fuzzy); entity cards with type, aliases, top relations.
kb_data_discover — list the live-data surface: connectors and named queries in scope, with param specs.
kb_data_lookup — run a named query with validated params; columns, capped rows, and a dataCallId provenance anchor.
eli_query — the full pipeline in one call: retrieval + entity resolution + governed lookups → a dual-cited [Sn]/[Dn] answer.

Once connected, just ask: "Using the eli tools, what do we know about the Order Platform — and is anything stuck right now?" The client will chain kb_entity_lookup → kb_data_discover → kb_data_lookup, or just reach for eli_query and let eli.ai do the whole job.

MCP vs. REST — which surface?

Use MCP when the consumer is an agent that should decide for itself when to search the KB, expand the graph, or hit live data. Tools are self-describing, so the model discovers what it can do and chains calls without you scripting the orchestration.
Use REST (/api/v1) when your code is in control — a backend that ingests documents, a service that generates reports, a pipeline that runs a fixed sequence. REST also covers the write and agent-run surface that MCP intentionally does not expose.
They share a key and a security model. The same eli_sk_ token works on both; both are read-scoped-by-key, RLS-isolated, and provenance-logged. Mix freely.

Same pipeline, plain HTTP

Not building an MCP client? eli_query is exactly POST /api/v1/query — the same grounded, dual-cited pipeline as ordinary JSON. Full details in MCP server.

The leverage

With one claude mcp add, an off-the-shelf agent gains grounded, workspace-scoped knowledge of your entire organization — no glue code, no prompt engineering to describe your schema, no credentials leaking into the model. The agent sees tools; you keep the governance. That is the fastest path from "we have a knowledge base" to "our assistants actually use it."