Use case

Give assistants the work, not the files.

Your team already works with AI assistants. Governed MCP tools let them extract, search and answer over company documents while the files stay home.

Deploy LM-Kit One Build with LM-Kit.NET
Files never leave Tool-level permissions Every call logged Standard MCP endpoint

The assistant is already here. The documents are the problem.

Teams paste sensitive files into chat tools today, or IT bans assistants outright and the productivity disappears. Both outcomes lose.

  • Shadow uploads. Staff paste contracts and customer data into whatever assistant answers fastest, outside every control you have.
  • Blanket bans. Blocking assistants protects the files and forfeits the value, and the ban erodes one exception at a time.
  • One-off connectors. Every internal integration hand-builds the same document plumbing, each with its own security review.
  • No audit trail. When leadership asks what left the network last quarter, nobody can answer from logs.

The assistant asks. The work stays home.

Four steps separate a useful assistant from an exposed file share, and all four are yours to set.

01

Connect

Any MCP-compliant assistant points at the LM-Kit One endpoint.

02

Govern

Administrators choose which tools are reachable and what they may return.

03

Work

The assistant calls tools; extraction, search and rendering run locally.

04

Audit

Every call is logged with what was disclosed, per owner.

A boundary you set, not one you hope for.

The assistant is a caller with credentials, a tool list and a log, the same as any other client you operate.

Clients

Any MCP client

Desktop assistants, coding agents and custom applications connect the same way; the endpoint speaks the standard protocol.

Disclosure

Results, never sources

The assistant receives what the allowed tool returns, not the file, the index or the folder behind it.

Identity

Sessions bound to an owner

Each session and the documents it may reach are bound to the authenticated owner, so callers cannot cross collections.

One endpoint, one key.

Point a compliant client at the endpoint and authenticate with an API key. The tool list it sees is the one you allowed.

mcp-config.json 
{
  "mcpServers": {
    "lm-kit-one": {
      "url": "https://lmkit.internal/mcp",
      "headers": { "Authorization": "Bearer <api key>" }
    }
  }
}

Expose tools, or consume them.

The protocol runs in both directions, and LM-Kit sits on both ends.

Expose

LM-Kit One

Runs the tools and the governance: permissions, disclosure rules, logging and the admin surface that operates them.

See LM-Kit One

Consume

LM-Kit.NET agents

Agents built with the SDK consume MCP servers too, so your own tools and third-party ones compose.

MCP in the SDK

This mode discloses what an allowed tool returns; the Trust Center states that boundary exactly.

The technology underneath.

Every guarantee on this page is a documented capability you can inspect on its own.

Protocol

MCP, both directions

The standard protocol assistants speak, exposed by LM-Kit One and consumed by SDK agents.

How MCP works here

Governance

Tool permissions

Typed metadata, allow and deny rules, risk levels and approval requirements per tool.

How permissions work

Execution

Tools & function calling

Atomic built-in tools executed server-side, one operation per tool.

How tools work

Grounding

RAG & grounded chat

The retrieval layer behind document search tools, with citations the assistant passes on.

How retrieval works

Private Document Intelligence

Wire an assistant to your documents.

Deploy LM-Kit One How MCP governance works