lemma_docs_mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LEMMA_DOCS_CORPUS_ROOT | No | Override the default corpus root directory for Lemma documentation. The default is `PPC/Product/PracticeOS/Lemma/docs/` (sibling of `MCP_Servers/`). This environment variable is optional; no environment variables are required. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| lemma_docs_contextA | Search the local Lemma (getlemma.com) documentation corpus and return focused, ranked source excerpts for a question or task. Lemma is healthcare-practice banking: entity accounts, deposit bonuses, fixed fee loans, cash sweeps, MSO-PC compliant banking guardrails, and shared onboarding. Routes the query into one of three internal namespaces (getting-started: quickstart/onboarding/KYB; guides: deposit bonuses, fixed fee loans, MSO-PC compliance, collaboration, owning multiple entities; product-updates: changelog and roadmap) and returns compact chunks with source paths. This is a local documentation index only — it NEVER calls live Lemma or banking APIs, and it cannot move money or mutate any account state. Coverage note: the corpus is the 8 pages Lemma exposes as markdown. Banking-operations pages (accounts, cards, transactions, move money), insurance/lockbox, invoicing, team-management, and the API reference are NOT in this index — say so instead of guessing when a query needs them. Args:
Returns (structured): { query, namespace, intent, guidance, chunks: [{ id, score, namespace, source_type, path, heading, excerpt, metadata }], pagination: { total_matches, count, offset, has_more, next_offset? }, follow_ups: [string], truncated?, truncation_message?, stats: { indexed_chunks, returned_chunks } } Chunk excerpts are capped; pass a chunk's id (or its path) to lemma_docs_get for the full text. Examples:
Errors:
|
| lemma_docs_getA | Fetch the full text of specific indexed Lemma documentation chunks by id, or every chunk of one document by its relative path. Use this after lemma_docs_context to expand excerpts you actually need — do not use it to browse (use lemma_docs_context for discovery). Reads the local corpus index only; it NEVER calls live Lemma or banking APIs. Args:
Returns (structured): { found: [{ id, namespace, source_type, path, heading, text, metadata }], missing: [string], truncated?, truncation_message? } Examples:
Errors:
|
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct roles: one performs ranked search/discovery over the corpus, the other retrieves full text for specific chunks or documents. There is no overlap or ambiguity between them.
Both tool names follow the same `lemma_docs_<verb>` pattern, with context indicating search/discovery and get indicating retrieval. The naming convention is consistent and predictable.
Two tools is on the thin side, but for a narrow local-documentation retrieval server the search-and-get pair is a reasonable minimal setup. It feels slightly sparse rather than fully fleshed out.
The server covers the core documentation workflow: discover relevant chunks and then expand them to full text. Notable gaps like listing all documents or browsing the corpus are acknowledged by the tool descriptions, and the search tool can surface paths, so agents can work around them.